Error response format
All errors return this structure:| Property | Always present | Description |
|---|---|---|
code | Yes | Machine-readable error code |
message | Yes | Human-readable description |
field | No | Dot-notation path to the problematic field (e.g., address.state). Only present when a specific field caused the error. |
request_id | Yes | Unique UUID for this request. Include in support tickets. |
Error codes
| Code | HTTP Status | Description |
|---|---|---|
VALIDATION_ERROR | 400 | Invalid request body or query parameters |
AUTHENTICATION_ERROR | 401 | Missing, malformed, or invalid API key |
AUTHORIZATION_ERROR | 403 | Valid key but not permitted (e.g., suspended account, disallowed payment type) |
NOT_FOUND | 404 | Resource not found or belongs to a different partner |
CONFLICT | 409 | Duplicate resource (same email, external_id, or billing period) |
RATE_LIMITED | 429 | Too many requests |
INTERNAL_ERROR | 500 | Unexpected server error |
Example error responses
400 — Validation Error
400 — Validation Error
401 — Authentication Error
401 — Authentication Error
404 — Not Found
404 — Not Found
409 — Conflict
409 — Conflict
Tips
- Always check for the
errorkey in the response before processing data. - Use
fieldfor field-level error highlighting in your UI. - Include
request_idwhen contacting support.