Error envelope
Every error response uses a consistent JSON envelope:| Field | Type | Description |
|---|---|---|
code | string | One of the 12 normalized error codes |
message | string | Human-readable description |
retryable | boolean | Whether retrying the same request may succeed |
request_id | string | Unique request identifier for support tickets |
details | array | Field-level validation errors (only for INPUT_VALIDATION_ERROR) |
Retry logic
Check theretryable field before retrying:
Rate limit errors
When rate limited, use theX-RateLimit-Reset header to determine when to retry:
Best practices
Always check the error code, not the HTTP status
Always check the error code, not the HTTP status
Multiple error codes map to the same HTTP status (e.g., 400 can be INPUT_VALIDATION_ERROR, CONTENT_MODERATION_REJECTED, FILE_NOT_FOUND, or FILE_FORMAT_UNSUPPORTED). Use the
code field for precise handling.Use idempotency keys for retries
Use idempotency keys for retries
When retrying failed requests, use the same idempotency key to prevent duplicate executions in case the original succeeded but the response was lost.
Log the request_id
Log the request_id
Include the
request_id when contacting support. It allows us to trace the exact request through our systems.Handle INSUFFICIENT_BALANCE proactively
Handle INSUFFICIENT_BALANCE proactively
Check your balance before submitting large batches. Set up auto-topup in the dashboard to avoid interruptions.