error.code, and branch on it. The
human message is for display and logging only — never parse it, because the
wording can change.
The error object
| Field | Description |
|---|---|
type | The broad category of the error (see Error types below). Derived from the HTTP status. |
code | A stable, machine-readable identifier. Match on this. Every value is listed in the Error codes reference. |
message | A human-readable explanation. For display and logging only — do not parse it. |
param | The request field that caused the error, when the error is field-specific. |
doc_url | A link to this error’s entry in the Error codes reference. |
details | On validation errors with more than one bad field, an array of { param, message } for every field that failed. |
request_id | The id of the request that failed (also on the X-Request-Id header). Quote it to support so we can find the exact request in our logs. |
Request IDs
Every response — success or error — includes anX-Request-Id header (for example
req_4f3c…). On errors it’s also in the body as error.request_id. Log it on your
side, and include it when you contact support so we can find the exact request fast.
Catch errors
Check for a non-2xx status, readerror.code, and decide what to do.
Error types
type groups errors by what generally went wrong, so you can pick a broad response
without listing every code. For the specific reason, use code.
| Type | HTTP status | What it means | How to respond |
|---|---|---|---|
authentication_error | 401 | Missing or invalid credentials. | Send a valid API key. Reconnect a social account if the code is SOCIAL_TOKEN_EXPIRED. |
permission_error | 403 | Valid key, but no access to this resource. | Check the resource belongs to your org and your plan includes API access. |
not_found_error | 404 | The resource doesn’t exist or isn’t yours. | Check the ID. Don’t retry without changing it. |
invalid_request_error | 400, 409, 413, 422 | Bad input or a request that can’t run in the current state. | Fix the request using code and param. Don’t retry unchanged. |
rate_limit_error | 429 | Too many requests. | Back off and retry (see below). |
api_error | 500, 502 | A problem on our end or with an upstream provider. | Treat as transient and retry with backoff. |
Handle rate limits
When you getrate_limit_exceeded (429), wait and retry. Prefer the Retry-After
header when it’s present; otherwise back off exponentially.
Handle transient errors
internal_error (500) and UPSTREAM_PROVIDER_ERROR (502) are usually temporary and
not a problem with your request. Retry with exponential backoff. For writes, retry
the same request rather than creating a new one, so you don’t duplicate work.
For anything in the invalid_request_error family, do not blindly retry — the
request needs to change first. Use code and param to fix it.
Next steps
See the full Error codes reference for everycode, what it means, and
how to resolve it. Each error’s doc_url links straight to its entry there.