Overview
All API errors use this shape unless otherwise noted:error string as human-readable context that may vary by endpoint.
In rare panic-recovery cases, the server may return a plain-text
500 Internal Server Error body instead of JSON.Errors shown in API Reference examples
These are the shared examples shown across API Reference response tabs:Complete Runtime Error Catalog (Public v2 API)
The following messages are returned by the current backend implementation for public v2 API endpoints and may be more specific than the shared examples above.This guide is for public v2 API behavior. Public v1 API endpoints may return different status codes and message texts.
401 Unauthorized
Internal API (session-based) also returns:
403 Forbidden
404 Not Found
400 Bad Request
405 Method Not Allowed
409 Conflict
429 Too Many Requests
500 Internal Server Error
Dynamic validation error format
For schema/validation failures, the API can return structured, field-level messages generated at runtime (for example missing required fields or enum/type mismatch). Typical patterns:request body: <field>: is missingrequest body: <field>: input must be one of <allowed_values>request body: <field>: input must not be nullrequest body: <field>: doesn't match expected schema due to one of the following reasons: {...}
- Treat all
400as non-retryable until request is fixed. - Surface the raw
errortext in logs for faster debugging. - Add client-side schema validation for high-volume paths.
Client handling checklist
- Parse JSON body and capture
status,error, and rate-limit headers. - Retry only retryable statuses (
429, and selected5xx) with backoff. - Do not retry
400,401,403,404,405blindly. - Keep pagination inputs stable (
cursor, filters, sort options). - Include endpoint, request payload hash, timestamp, and error text in logs.

