Skip to main content
Core errors use an error machine identifier, with optional diagnostic fields. OAuth errors may include error_description; provider browser helpers can instead return code and message. Match the machine identifier, not diagnostic prose. The starter wraps some refusals in its own user-facing error text; do not parse that text as a core error code. The generated API reference defines each operation’s response shapes and status codes. Never retry a protected refusal anonymously. Never automatically retry a write with a fresh intent after an uncertain result. Preserve the original intent for an explicit same-request retry; see mutation retries.

Complete public error catalog

The catalog includes domain refusals, lifecycle/recovery admission refusals and OAuth/provider protocol errors. A code’s meaning does not make every code possible on every endpoint; use that operation’s reference for its status and shape. For invalid_client, check server-side credentials and client authentication; ask the operator to repair registration if needed. For invalid_grant or invalid_token, discard unusable delegated authority and restart authorization, rather than reusing a consumed code or rotated refresh token. For invalid_scope, correct the requested set and obtain registration approval/consent as needed. For access_denied, respect the user’s decision. For temporarily_unavailable and server_error, back off; do not loop through browser authorization. For login, account-selection, interaction or consent requirements, let the user complete the indicated provider browser step. Storage, witness and recovery failures are fail-closed. Do not serve a cached protected body while they persist. Diagnostic descriptions can change and must not become UI identifiers or be logged together with credentials, callback URLs or cookie values.