Errors
The API uses standard HTTP status codes and returns a consistent JSON error format.
All error responses follow this structure:
| Field | Type | Description |
|---|
success | false | Always false for errors |
error.code | string | Machine-readable error code |
error.message | string | Human-readable description |
Status codes
| Status | Code | Meaning |
|---|
400 | BAD_REQUEST | Invalid request parameters or body |
401 | UNAUTHORIZED | Missing or invalid API key |
403 | FORBIDDEN | Valid key but insufficient scopes |
404 | NOT_FOUND | Resource doesn’t exist or isn’t accessible |
429 | RATE_LIMITED | Too many requests — see Rate Limiting |
500 | INTERNAL_ERROR | Unexpected server error |
For security, requesting a resource that exists but belongs to another organization returns 404 (not 403). This prevents ID enumeration attacks.
Handling errors
Tips
- Always check
success in the response body, not just the HTTP status
- Log the full error response in production for debugging
- Implement retries for
429 and 5xx errors with exponential backoff
- Don’t retry
400, 401, 403, or 404 errors — they require code or configuration changes