Rate Limits

Every endpoint is rate limited per source IP, per endpoint over a sliding one-minute window. The bucket is per endpoint route, not per URL: all calls from one IP to, say, GET /public/payments/{id} share one bucket whatever the payment ID. Exceeding the limit returns 429 rate_limit_exceeded with a Retry-After header (in seconds) — it always carries the full window length, not the exact time until a slot frees up.

Currently every bucket allows 300 requests per minute. This figure is subject to change — contact support if your integration needs a higher ceiling.

A rejected request still counts against the window, so retrying immediately after a 429 only extends the lockout.

Handling 429

• Honor Retry-After. Wait the indicated number of seconds before retrying — do not retry immediately or in a tight loop.
• Design polling with sensible intervals. Status inquiry (statusOnly=true) and verify-reconciliation loops should poll at a measured cadence, not as fast as possible.
• Prefer the push channel. Webhooks exist precisely so you don't have to poll aggressively — react to the webhook, then verify, rather than hammering a read endpoint.

If your integration legitimately needs a higher ceiling, contact support.