Skip to main content

Agent API (/v1)

Used by: n8n, Zapier, MCP, and any HTTP client. Get X-Agent-Id and X-Api-Key from Credentials. Per-request timeout overrides in the JSON body are REST-only. The MCP integration does not forward timeout; expiry always uses the agent’s dashboard defaults unless you call this API over HTTP. Most routes require agent authentication (X-Agent-Id and X-Api-Key). The exception is GET /v1/agents, which lists agents for a workspace using X-Api-Key only (for example Zapier’s agent picker). A machine-readable description of these endpoints is available as OpenAPI YAML. For plan and quota errors on create, see Automation limits & billing.

GET /v1/agents

Lists active agents for the team that owns the workspace API key. Used by integrations that first authenticate with the key, then let the user pick an agent.

Request

Success response (200)

JSON array of objects: Agents are sorted by name ascending (null/empty names sort with Postgres rules; clients may still show id when name was missing).

Error responses


Approval status values

The status field describes the approval lifecycle (human choice or expiry). Values you will see on GET /v1/approvals/:requestId, GET /v1/approvals/:requestId/result, and in callback bodies: The create response’s status is pending for a newly created row.

Result delivery fields

On GET /v1/approvals/:requestId only, the API also returns how the final outcome was (or was not) handed off when a callback URL was configured on create. This is separate from approval status above. If you did not set callback.url on create, the service still tracks completion via polling; result_delivery_status typically stays pending from a “callback delivery” perspective even after the approval is resolved.

Callback webhooks

If you include callback on POST /v1/approvals, the service sends the outcome to your URL when the request leaves pending (human resolution or timeout expiry).

Request the service makes to your URL

Expiry-driven resolutions trigger the same callback path once the timeout worker marks the request expired.

Rate limits

POST /v1/approvals is additionally limited by a per-agent sliding window in the API process to absorb bursts. Default in the reference server configuration: 60 successful create attempts per agent per 60 seconds (your deployment may override AGENT_CREATE_RATE_LIMIT_MAX and AGENT_CREATE_RATE_LIMIT_WINDOW_MS). When exceeded, the API returns 429 with { "error": "rate_limited" }. Backoff and retry with jitter; do not spin in a tight loop.

POST /v1/approvals

Creates an approval request. The body must match the API validation rules below.

Request body

Omitting timeout: The server merges a missing timeout with the agent’s saved defaults (default_timeout_seconds, default_timeout_mode, default_timeout_instruction). If you include timeout, only the properties you set replace the corresponding defaults; omitted properties keep the agent values. The merged timeout is validated (including instruction required for expire_with_predefined_instruction) and used for expires_at and idempotency hashing. Omitting request_id: The create response always includes request_id (either yours or the server-generated UUID). Use that value for polling. Repeating POST /v1/approvals without a client request_id assigns a new id each time, so blind retries can create duplicate approvals. For safe retries, send the same request_id you chose on the first attempt.

Success response (200)

idempotent is true when this call matched an existing equivalent request for the same idempotency identity (only when you supplied a request_id; server-assigned ids are never merged across calls).

Error responses

409 idempotency_conflict body (in addition to error):
Use a new request_id when you intend a separate approval; repeat the same body to retry safely.

GET /v1/approvals/:requestId

Returns metadata for an approval identified by your external request_id (the path parameter is that same string). Use this for dashboards or to inspect callback delivery state; use /result for the full outcome payload.

Success response (200)

status follows Approval status values. result_delivery_status / result_delivery_error are described under Result delivery fields.

Error responses


GET /v1/approvals/:requestId/result

Polls the outcome. The path parameter :requestId is your external id (request_id from creation).

Pending (200)

Resolved (200)

Includes fields such as:
  • request_id, agent_id, correlation_id
  • status — one of selected_option, custom_instruction, or expired (see Approval status values)
  • selected_option_index, selected_option_label (when applicable)
  • custom_instruction
  • resolved_by (user_id, name), resolved_at
This is the same JSON shape POSTed to your callback.url, if configured.

Error responses