Error Response Format
All API errors follow a consistent format:HTTP Status Codes
| Status Code | Description |
|---|---|
200 | Success |
201 | Created |
204 | No Content |
400 | Bad Request |
401 | Unauthorized |
403 | Forbidden |
404 | Not Found |
409 | Conflict |
422 | Unprocessable Entity |
429 | Too Many Requests |
500 | Internal Server Error |
Error Codes
Authentication Errors
| Code | Status | Description |
|---|---|---|
unauthorized | 401 | Missing or invalid API key |
invalid_api_key | 401 | API key is malformed or revoked |
expired_api_key | 401 | API key has expired |
forbidden | 403 | API key lacks required permissions |
Validation Errors
| Code | Status | Description |
|---|---|---|
invalid_request | 400 | Request body is malformed |
missing_field | 400 | Required field is missing |
invalid_field | 422 | Field value is invalid |
invalid_format | 422 | Field format is incorrect |
Resource Errors
| Code | Status | Description |
|---|---|---|
not_found | 404 | Resource does not exist |
already_exists | 409 | Resource already exists |
conflict | 409 | Operation conflicts with current state |
Rate Limit Errors
| Code | Status | Description |
|---|---|---|
rate_limited | 429 | Too many requests |
Server Errors
| Code | Status | Description |
|---|---|---|
internal_error | 500 | Unexpected server error |
service_unavailable | 503 | Service temporarily unavailable |
Handling Errors
Python Example
HTTP Example
Request IDs
Every API response includes arequest_id in the meta object. Include this ID when contacting support about errors:
Best Practices
Implement retries with backoff
Implement retries with backoff
For transient errors (429, 500, 503), implement exponential backoff:
Log request IDs
Log request IDs
Always log the
request_id from error responses for debugging.Handle rate limits gracefully
Handle rate limits gracefully
Check the
Retry-After header or retry_after field and wait before retrying.