Skip to main content
The API uses standard HTTP status codes. 2xx succeeded, 4xx means your request was rejected, 5xx means something failed on our side.

​
Reading an error

Always branch on the HTTP status code, and read message for the detail. Error bodies are not identical across every endpoint — some carry statusCode and error, others carry success and error_code. Both always include message, and both put structured detail in data.
Don’t key your error handling off error_code or success alone — they aren’t present on every error. The HTTP status code is the reliable signal.
Successful responses are consistent:

​
Status codes

​
Validation errors

For validation failures, data.errors lists the individual field problems:

​
Suspended customers

If a customer_key belongs to a suspended customer, the request returns 403 with the date the suspension lifts:

​
Rate limits

Limits are counted per endpoint, per API key — a busy status-check loop won’t eat into your ability to create transactions. Because the count is per key, every server sharing a key shares its budget. If you run several workers in parallel and keep hitting limits, give them separate keys rather than raising the limit. They’re grouped by what the endpoint does: The burst limit catches rapid-fire requests inside a few seconds even when you’re under the sustained limit, so pace retries rather than firing them together. A separate protection at our network edge caps sustained traffic from a single IP address across all endpoints. Normal integrations never reach it, but a fleet of workers sharing one outbound address can. If you’re getting 429s that don’t line up with the per-endpoint limits above, that’s usually why — contact support and we’ll confirm.
These are the standard limits. They’re configurable per account, and high-volume integrators can be raised or exempted — talk to your account manager, or reach support through your usual channel, if you’re designing something that needs it.

​
Handling a 429

data.retryAfter tells you how many seconds to wait. Wait at least that long, then retry — don’t retry immediately, and don’t retry in a tight loop.

​
Staying under the rate limits

  • Use webhooks instead of polling. Polling for transaction status is the single most common cause of hitting these limits. See Webhooks.
  • Batch your lookups. Use list endpoints with pagination rather than looping one-by-one lookups.
  • Back off on 429. Honour retryAfter rather than retrying on a fixed timer.
  • Spread parallel workers. If several workers share one outbound IP, they share the infrastructure limit too.