Three small endpoints tell you what the API is doing right now and what you may do next. Read them before you act, or after a retryable error.

Network status

GET /v1/network is public and cheap: it reads cached results of background probes that run about once a minute, and it never calls a provider on your behalf.
Each component has an id, a status (operational, degraded, down or unknown), a short snake_case reason (null when operational), the actions it affects, since (when it entered this status) and checked_at. A probe that times out or errors reports probe_failed. One failed probe reads degraded. Two in a row read down. Every component is unknown until its first probe.
The status is advisory. The API never refuses a request because of it, so an action can succeed while a component reads down, and fail while it reads operational. Read it after route_unavailable or provider_unavailable. If a component your action depends on is down, wait and retry later instead of changing the request. After a provider_unavailable that is a recorded execution outcome (no meta.retryable), check one_click and send the work again under a new Idempotency-Key once it reports operational.

Quotas

GET /v1/quotas shows your limits and what you have used.
overrides lists limits the operator changed for your account, and revision counts those changes. limits is what applies to you now. The numbers above are the defaults. Always read your own. limits and usage cover only agents created per day, API keys and the two request rates. The deposit, grant, wait and cooldown limits in the table below are not in the response.

Limits

The partner-account request limit, the agent limit and the deposit limit are shared by all of your keys, so creating more keys never raises them. Request limits apply to every call that needs an API key. GET /v1/network and GET /v1/tokens need none.

GET /v1/whoami

Checks that a key works and says which partner account it belongs to.

HTTP 429

A 429 means “later”. These codes carry the time to retry: Each of them returns:
  • errors[0].meta.retryable: true
  • errors[0].meta.available_at, an ISO 8601 time when the limit frees up
  • a Retry-After header with the wait in whole seconds
The edge also caps each client IP address per 10 seconds, before a request reaches the API. It answers rate_limited (429) with Retry-After: 10 and errors[0].meta.retryable: true, but no meta.available_at. Retry after 10 seconds. provider_rate_limited is also a 429, but it comes from a service behind the API. It has no available_at. On reads it is retryable with a Retry-After; on an execution the refusal is recorded, so send the work again under a new key after a short wait.
Retry a 429 on a write with the same Idempotency-Key and the same body. Never switch to a new key to get past a limit, because a request the API already accepted would run twice. A refusal recorded for an action is replayed under its key, so for those, see Status & Errors.

Next steps

Status & Errors

Every error code, with its HTTP status and what to do.

Executions

Run actions under a grant.