Error Handling
How errors are structured, the standard error codes, and how to debug a failing request.
Error Shape
Every error response uses the same envelope as a successful response, with success: false:
Error response
{
"success": false,
"data": null,
"error": {
"code": "validation_error",
"message": "quantity must be greater than 0",
"field": "quantity"
}
}HTTP Status Codes
| Status | Meaning |
|---|---|
| 400 | Bad request — malformed input or failed validation. |
| 401 | Missing or invalid credentials. |
| 403 | Authenticated, but not permitted to perform this action. |
| 404 | The resource doesn’t exist, or isn’t visible to your account. |
| 429 | Rate limit exceeded — see Rate Limits. |
| 500 | Unexpected server error. Safe to retry with backoff. |
Error Codes
| Code | Description |
|---|---|
validation_error | A field in the request body failed validation. |
invalid_credentials | The API key or token is missing, malformed, or expired. |
permission_denied | The authenticated account’s role or scope doesn’t allow this action. |
not_found | The resource ID doesn’t exist or isn’t visible to this account. |
rate_limited | Too many requests — see the Retry-After header. |
404 vs. 403
To avoid leaking whether a resource exists, requests for records outside your permission scope return
404 not_found rather than 403 permission_denied.Debugging Guide
- Check the
error.fieldvalue on validation errors — it points to the exact offending field. - A sudden wave of
401s usually means a key was rotated or revoked — check your developer settings. - Confirm the account tied to your API key actually has the role required for the endpoint you’re calling.
- For anything unclear, include the request ID from the
X-Request-Idresponse header when contacting support.