Error Handling
HTTP status codes, error response format, typed SDK exceptions, and retry strategies.
All API errors return a consistent JSON structure. The SDKs throw typed exceptions so you can handle each case explicitly.
Error response format
Every error includes a request_id for debugging. Include it when contacting support.
HTTP status codes
| Code | Type | Description | Retryable? |
|---|---|---|---|
400 | bad_request | Malformed request | No |
401 | authentication_error | Missing or invalid API key | No |
403 | forbidden | Insufficient permissions | No |
404 | not_found | Resource does not exist | No |
409 | conflict | Duplicate resource | No |
422 | validation_error | Request body failed validation | No |
429 | rate_limit_error | Rate limit or quota exceeded | Yes |
500 | server_error | Internal server error | Yes |
502 | bad_gateway | Upstream service error | Yes |
503 | service_unavailable | Service temporarily down | Yes |
SDK error handling
The SDKs throw typed exceptions that you can catch individually — no string matching needed.
The SDKs automatically retry 429 and 5xx errors with exponential backoff (up to maxRetries times). You don't need to implement retry logic for these cases.
Rate limits
When you exceed per-endpoint rate limits, the API returns 429 with Retry-After and X-RateLimit-* headers. The SDKs automatically retry these with exponential backoff.
See Limits & Quotas for the full rate limit table by endpoint.
Custom retry logic
If you need custom retry behavior beyond what the SDKs provide:
Quota errors
If you exceed your plan's monthly limits, query and ingest endpoints return 429 with a message indicating which quota was exceeded.
Check your current usage with the status endpoint:
See Limits & Quotas for plan details.