Error Response Format
All errors follow a consistent envelope:Error Codes
| Code | HTTP Status | Description |
|---|---|---|
UNAUTHORIZED | 401 | Invalid, expired, or missing API key |
NOT_FOUND | 404 | Resource doesn’t exist or you don’t have access |
VALIDATION_ERROR | 422 | Invalid request parameters (check param field) |
RATE_LIMITED | 429 | Too many requests (check retry_after field) |
INTERNAL_ERROR | 500 | Something went wrong on our end |
Error Fields
| Field | Type | Description |
|---|---|---|
type | string | Stable URI for this error type (inspired by RFC 9457) |
code | string | Machine-readable error code for programmatic handling |
message | string | Developer-facing explanation with details |
display_message | string | null | Safe to show to end users in a UI |
param | string | null | Which request parameter caused a validation error |
retry_after | number | null | Seconds until you can retry (only on RATE_LIMITED) |
Handling Errors
Request IDs
Every response includes arequest_id in the meta object and as an X-Request-Id response header. Include this when contacting support about a specific request.