code, such as run_not_found or insufficient_credits. This catalog lists all of them with their HTTP status and whether retrying can help, and links each code to a page with its exact trigger, the fix, and a sample body. Use it when you have a code in hand and need to know what to do next.
Each code has a page at /problems/{code}, and the path is the snake_case code itself: /problems/scope_denied, not /problems/scope-denied. For the shape of the error body and how to parse it, see Errors.
Start with the status
A few rejections arrive as plain text with no
code at all (400, 404, 405, 413, 415, 422). Classify those by status; see plain-text rejections.
What “Retryable” means
- yes: the same request can succeed later. Back off exponentially with jitter. On
POST /v1/runs, send a newIdempotency-Keyafter a 5xx, because the failed run keeps the old one. - later: waiting can help, but not seconds of backoff. A 429 clears when in-flight runs settle or the quota period resets.
- after top-up: the request succeeds once your balance covers it. The same
Idempotency-Keyis reusable. - no: retrying changes nothing. The request, the credential or the id has to change first.
All codes
Request errors (400)
Credential and permission errors (401, 403)
Account errors (402, 429)
Lookup and state errors (404, 409)
Size errors (413)
Run execution errors (500, 503, 504)
Service errors (503)
Handle codes in code
Map the codes your client can act on, and fall back to the status for everything else.Related
- Errors - the error envelope, plain-text rejections and the retry rules.
- Error handling - a complete retry loop for
POST /v1/runs. - Idempotency - when a retry needs a new
Idempotency-Key. - Troubleshooting - symptoms that do not come with a code.