Error Response Format
HTTP Status Codes
Error Code Reference
Authentication Errors (401)
Errors related to verifying your identity.Authorization Errors (403)
Errors related to permissions and access control.Plan restrictions
Advanced analytics, A/B testing, translations and inviting teammates are part of the Teams plan. A request for one of them from an account on another plan fails withAUTHZ_PLAN_RESTRICTION, and the response says which capability was needed and what would unlock it:
Validation Errors (400)
Errors related to request format and data validation.Resource Errors (404, 409, 410)
Errors related to resource existence and conflicts.Rate Limiting Errors (429)
Errors related to request frequency limits.Quota Errors (402, 413, 429)
Errors related to usage limits and billing.Business Logic Errors (409, 422)
Errors related to business rules and state conflicts.Partner Errors (402, 403, 404, 409, 422, 429, 502, 503)
Errors a partner integration meets: the standing of the account, its storage, its customers and what they may spend. Branch onerror.code; error.details carries the machine-readable facts. Each page of the guide lists the errors of its own calls too.
External Service Errors (502, 503, 504)
Errors related to third-party dependencies.System Errors (500, 503)
Internal system errors.Handling Errors
JavaScript/TypeScript
The SDK throws aResponseError for every answer that is not a success. The HTTP status is error.response.status, the response headers are error.response.headers, and the body is the error format shown above: read it with await error.response.json(). error.code holds the machine-readable code from that body.
Using Correlation IDs
Every error response includes acorrelationId. Include this when contacting support:
Retry Strategies
Exponential Backoff
For transient errors (429, 503, 504), implement exponential backoff:Idempotent Retries
For POST/PUT operations, use idempotency keys to safely retry:See Idempotency for more details on safe retries.
A
409 with the code CONFLICT_IDEMPOTENCY_IN_PROGRESS means your earlier request with the same key is still running. It is safe to retry: wait for the Retry-After header and resend with the same key. A 409 with the code CONFLICT_IDEMPOTENCY_ANSWER_UNAVAILABLE means that request already succeeded and was not run again, but its response can no longer be returned: do not retry it with the same key; see When the stored response is no longer available. Any other 409 is not retryable as-is.Best Practices
Always Handle Errors
Always Handle Errors
Never assume API calls will succeed. Always wrap calls in try/catch and handle specific error codes.
Log Correlation IDs
Log Correlation IDs
Store correlation IDs in your logs for debugging and include them in support requests for faster resolution.
Implement Backoff for Rate Limits
Implement Backoff for Rate Limits
For rate limiting (429), use exponential backoff with jitter. Always check the
Retry-After header.Validate Before Sending
Validate Before Sending
Validate data client-side before making API calls to catch validation errors early and reduce unnecessary requests.
Handle Plan Restrictions Gracefully
Handle Plan Restrictions Gracefully
When you receive
AUTHZ_PLAN_RESTRICTION or QUOTA_* errors, provide users with clear upgrade paths or alternatives.