4xx/5xx) and a JSON body in the
standard format below.
Error format
| Field | Always present | Description |
|---|---|---|
code | Yes | Stable, machine-readable code (e.g., NOT_FOUND, VALIDATION_ERROR). |
message | Yes | Human-readable message (fallback in pt-BR). |
key | No | i18n key, when the message is translatable. |
params | No | Message interpolation parameters (e.g., { "email": "..." }). |
details | No | Additional details (e.g., per-field errors on validation). |
HTTP codes
| Status | Typical code | Meaning | What to do |
|---|---|---|---|
400 | VALIDATION_ERROR | Invalid body/parameters. | Fix the payload. Check details. |
401 | UNAUTHORIZED | Missing or invalid API key. | Check the x-api-key header. |
403 | FORBIDDEN | Insufficient permission for the operation. | Check the key type/scope. |
404 | NOT_FOUND | Resource does not exist (or belongs to another account). | Verify the ID. |
409 | CONFLICT | State conflict (duplicate, invalid transition). | Handle the specific case. |
422 | UNPROCESSABLE_ENTITY | Request understood but cannot be processed. | Review the business rule. |
429 | RATE_LIMIT_EXCEEDED | Request rate limit exceeded. | Wait and retry with backoff. |
500 / 502 / 503 | INTERNAL_ERROR | Server-side error. | Retry with backoff; if it persists, contact support. |
Validation errors (400)
When one or more fields are invalid, details provides a message per field:
Recommended error handling
Retry with backoff
On
429 and 5xx, retry with exponential backoff. Combine with Idempotency-Key to avoid
duplicating the operation.Do not retry on 4xx
400/409/422 will not resolve by retrying — fix the request instead.Log the code and request id
Store the
code, status, and response body for diagnostics. Do not log the API key.Always use idempotency
For write operations, use
Idempotency-Key to make retries safe. See
Conventions.
