Always check the HTTP status code first. Then use the error
code field for programmatic handling.Error response format
Common HTTP status codes
| Status code | Meaning |
|---|---|
200 | Request completed successfully |
201 | Resource created successfully |
400 | Bad request |
401 | Authentication failed |
403 | Permission denied |
404 | Resource not found |
409 | Duplicate or conflicting request |
422 | Validation error |
429 | Too many requests |
500 | Server error |
Common error codes
| Code | Meaning |
|---|---|
authentication_failed | The API key is missing, invalid, or inactive |
invalid_request | The request body is malformed or missing required fields |
validation_error | One or more fields failed validation |
resource_not_found | The requested resource does not exist |
duplicate_request | The idempotency key or transaction reference has already been used |
insufficient_balance | The merchant does not have enough balance for the request |
transaction_failed | The transaction could not be completed |
rate_limit_exceeded | Too many requests were sent in a short period |
server_error | An unexpected server error occurred |
Validation error example
How to handle errors
Check the status code
Use the HTTP status code to decide whether the request failed because of authentication, validation, permission, or server issues.
Best practices
- Log the status code, error code, and request reference when a request fails.
- Do not expose raw server messages to end users without context.
- Retry only when the request is safe to repeat.
- Use idempotency for create and payout requests.
- Contact support if you repeatedly receive
server_errorresponses.