Rate limits and allowances

Request rate, asset intake capacity, storage allowance, an API key's spend limit or your balance may refuse a new request. Handle limits by their error codes; these docs never fix the numbers.

Rate limits

Too many requests return 429 rate_limited. The response may carry Retry-After (1–3600 seconds): wait that long, then retry with the same Idempotency-Key.

Large-request concurrency

Each team can send only a few creation requests with bodies over 2 MiB at the same time. When they are all in use the answer is 429 rate_limited without Retry-After: retry a little later. A large body must arrive within 120 seconds.

Balance and API key limits

When your balance cannot cover the reservation the answer is 429 insufficient_balance, with the reservation needed in error.details; top up and retry with the same key. When an API key has a spend limit, new requests are refused once it is used up as well: handle them by the returned code.

Asset allowances

• 429 asset_storage_quota_exceeded: your team's asset storage allowance is used up; Retry-After does not apply.
• 429 asset_intake_rate_limit_exceeded: asset intake capacity is limited; retry later.

Paused intake

503 funding_intake_closed means new tasks are not accepted for now; exact replays of accepted requests still return their response. Try again later.

Next steps

Handle errorsThe shape of error responses, and which errors you can retry as they are.Idempotency and retriesRetry with the same Idempotency-Key to get exactly one task and one charge.