Rate limits

Task starts, continues, and executes are governed by your credit balance, not by a per-minute quota. A run that exhausts credits fails with 402, not 429; see Errors. Two surfaces have a quota, per account:

Route	Limit
`GET /task/{task_id}`	180 per minute, 20,000 per day, and 2 requests in flight at once.
`POST /upload-url`	30 per minute, 2,000 per day.

The 429 body

{
  "error": "rate_limited",
  "message": "Too many task reads; retry shortly.",
  "retryable": true,
  "retry_after": 10,
  "request_id": "req_3f9c2a1b0d4e5f6a7b8c"
}

retry_after is in seconds. The same value is sent as the Retry-After header.

Handling 429

Wait retry_after seconds, then send the same request again. A 429 is transient: the task, the file, and the task_id are all still valid, so the retry picks up where it left off. Polling is the usual cause. Poll GET /task/{task_id} no faster than once every few seconds, or use GET /task/{task_id}/stream and let the server push events instead.

Credits

Check the balance any time:

curl -sS "https://api.autumn.ai/credits" \
  -H "X-API-Key: $AUTUMN_API_KEY"

Status responses also carry credit usage for the task, so you can attribute spend per run rather than only in aggregate.

Reference

Endpoints

The 429 body

Handling 429

Credits

​The 429 body

​Handling 429

​Credits

The 429 body

Handling 429

Credits