Error Handling

Error Response Format

All error responses follow a consistent structure:

{
  "message": {
    "code": 400,
    "error": ["Description of the error"]
  },
  "data": [],
  "type": "error"
}

Field	Type	Description
`message.code`	integer	HTTP status code
`message.error`	array	List of error messages
`data`	array/object	Empty on error
`type`	string	Always `"error"` for failed requests

Handling Strategies

400 — Bad Request

Cause: Missing required fields or invalid parameter values.Action: Check your request body against the endpoint documentation. Validate all required fields before sending.

{"message": {"code": 400, "error": ["The amount field is required"]}}

403 — Forbidden

Cause: Invalid, expired, or missing authentication token.Action: Request a new access token and retry. Ensure your API keys are correct.

{"message": {"code": 403, "error": ["Requested with invalid token!"]}}

422 — Unprocessable Entity

Cause: Valid request format but invalid business logic (e.g. cancelling a paid order).Action: Check the current state of the resource before attempting the action.

{"message": {"code": 422, "error": ["Only pending orders can be cancelled"]}}

429 — Rate Limited

Cause: Too many requests in a short period.Action: Implement exponential backoff. Wait, then retry with increasing delays.

$delay = min(pow(2, $attempt) * 100, 30000); // max 30s
usleep($delay * 1000);

Never expose raw API error messages to end users. Map error codes to user-friendly messages in your application.

Getting Started

Reference

Error Response Format

Handling Strategies

​Error Response Format

​Handling Strategies

Error Response Format

Handling Strategies