Concepts

Errors and retries

The error format, common error codes, and how to retry safely.

Error format

Errors are JSON with a machine-readable code, an HTTP status, a human-readable message, and sometimes structured data:

{
  "code": "INSUFFICIENT_BALANCE",
  "status": 422,
  "message": "Insufficient balance to approve this payout",
  "data": {
    "walletBalance": "50.00",
    "totalOpenAmount": "150.00",
    "currency": "EUR"
  }
}

Common codes

StatusCodeMeaning
401UNAUTHORIZEDMissing or invalid token
403FORBIDDENToken lacks a required scope or permission
404NOT_FOUNDResource does not exist for the authenticated team
409CONFLICTUpdate rejected, e.g. an immutable payout
422INPUT_VALIDATION_FAILEDThe request body failed validation; message is a readable summary and data carries per-field issues
422INSUFFICIENT_BALANCEPre-approved payout exceeds the team wallet balance
500INTERNAL_SERVER_ERRORUnexpected server fault

Retry guidance

  • 4xx errors are yours to fix — retrying the identical request fails again (except 429).
  • 5xx errors and network timeouts are safe to retry with exponential backoff. Payout creation is an upsert keyed on customId, so a retried create never duplicates a payout — see Idempotency.
  • Write clients that ignore unknown fields: additive changes (new endpoints, new optional fields, new enum values) are not breaking and happen without notice. See Breaking changes.