Skip to main content
Every error in the API answers the same envelope:
string
Stable. It is the contract — branch on this.
string
For a person. It may change wording between releases, and it may be in a language you did not ask for. Never parse it.
Map codes to your own copy, and fall back to message for a code you do not recognize — that way a new code degrades to something readable instead of a blank dialog.

Codes by status

400 — the request is wrong

401 — no valid credential

403 — authenticated, not allowed

404 — not here

404 is also how cross-tenant and cross-environment reads answer. It never reveals that the resource exists somewhere else — the id you hold is simply not addressable with the credential you hold.

409 — the state says no

422 — permanently failed

429 — too many

See Rate limits.

5xx — ours

501 — the server cannot do this

These are platform states, not user errors. GET /v1/session reports two_factor_available and uploads_available so a client can hide the feature instead of discovering it here.

Handling them

Two things that are not errors

A pagination value out of range falls back to the default rather than answering 400. Do not rely on a 400 to catch a bad page size. 202 on the non-enumerable endpoints is a success. It does not mean “queued” and it does not mean the address exists — it means the answer would be the same either way.