Skip to main content
Every non-2xx response from the Bonya API is an RFC 9457 application/problem+json body.

​
Shape

​
string
required
A URI identifying the problem type.
​
string
required
A short, human-readable summary of the problem.
​
integer
required
The HTTP status code, repeated in the body for convenience.
​
string
required
A stable, machine-readable error code.
​
string
A human-readable explanation specific to this occurrence of the problem.
Branch your error handling on code, not on status or title. code is the stable, machine-readable field this API guarantees; status and title are for humans and logs.

​
Known error codes

These are the named code values documented in the API contract, the HTTP status they arrive with, and the operation that returns them. This list covers the error codes named explicitly in the API contract. Other operations return Problem responses too (for example, malformed input generally, or a 404 for an unknown or cross-organization resource) — those follow the same shape but don’t have a single contract-documented code literal beyond what’s listed above.
A 404 is also the deliberate response for both “doesn’t exist” and “exists but isn’t yours” — for example, a well-formed X-Bonya-Organization-ID for an organization you don’t belong to returns 404, not 403, so the API doesn’t confirm the organization’s existence to non-members. Accepting an invitation token — unknown, addressed to someone else, already consumed, revoked, or expired — is likewise a single indistinguishable 404 rather than a code that would let you tell those cases apart.