Errors
One envelope for every error, with stable machine-readable types.
Every error response (auth failures, validation rejections, rate limits, server faults) carries the same JSON envelope:
type: a stable, machine-readable identifier. Branch on this, never onmessage.message: human-readable detail. Wording can change without notice.request_id: matches theX-Request-IDresponse header. Include it when contacting support; it lets us find the exact request.details: optional object carrying the narrow, contract-level context a caller needs in order to act (for examplecurrent_versionon a409version conflict). Absent when there is nothing actionable to add.
Adding a new type is a non-breaking change; renaming or removing one is
breaking and versioned. Treat an unrecognized type according to its HTTP
status class.
Status codes
Common error types
Embed-session minting and exchange have their own type family
(invalid_embed_token, embed_token_expired, embed_scope_not_allowed,
invalid_session_handle, …) documented alongside the
Embed flow.