Skip to main content
This page is the API-reference view of failures. For a task-oriented guide, see Error handling.

Decoding algorithm

Status codes

Stable error codes

These come from middleware and guards, and are safe to branch on.

Codes you should not require

Some internal errors define codes that are not guaranteed to reach clients. In particular, trial upload-limit violations are detected internally, but the upload controller’s error path does not always forward the code. Practical rule:
Branch on code when present. Always have a status-based fallback. Never fail because a code is missing.

Authorization failure triage

A 404 on a resource you believe exists is often a visibility problem, not a deletion. Verify the bucket and the key’s restriction before assuming data loss.

Nested-status operations

These return HTTP 200 with the real outcome inside the body: Example of a nested failure:
Do not treat the outer 200 as success.

Rate limit responses

429 responses use API_KEY_RATE_LIMITED. No Retry-After header is documented. Use exponential backoff with jitter:
Do not retry 401, 402, or 403.

Error handling example

Error handling

Task-oriented guide with retry patterns.

Error codes

Full code reference.

Troubleshooting

Symptom-to-cause table.

Conventions

Envelope shapes.