Skip to main content

Overview

All API errors use this shape unless otherwise noted:
Use the HTTP status code as the primary signal. Treat the 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 missing
  • request body: <field>: input must be one of <allowed_values>
  • request body: <field>: input must not be null
  • request body: <field>: doesn't match expected schema due to one of the following reasons: {...}
Recommended handling:
  1. Treat all 400 as non-retryable until request is fixed.
  2. Surface the raw error text in logs for faster debugging.
  3. Add client-side schema validation for high-volume paths.

Client handling checklist

  1. Parse JSON body and capture status, error, and rate-limit headers.
  2. Retry only retryable statuses (429, and selected 5xx) with backoff.
  3. Do not retry 400, 401, 403, 404, 405 blindly.
  4. Keep pagination inputs stable (cursor, filters, sort options).
  5. Include endpoint, request payload hash, timestamp, and error text in logs.