Skip to main content
Rate limits are scoped to each secret API key and reset over one-minute windows. They protect live payment operations without restricting normal transaction volume.

​
Limits

Transaction operations include creating checkouts, payment intents, payment attempts, refunds and payouts. The 60,000-request limit is a safety ceiling, not a recommended operating target. Always use an idempotency key when retrying a POST request. Reads served from Orqex include list and retrieve endpoints. They return the latest state stored by Orqex without forcing a live status refresh. Live operations contact the upstream payment service. This category includes:
  • POST /payment/intents/{paymentIntentId}/requery
  • GET /payment/intents/{paymentIntentId}/attempts/{attemptId}/inspect
  • GET /payouts/{payoutId}/sync
  • GET /payouts/{payoutId}/inspect
The per-resource limit prevents one aggressively polled transaction from consuming the shared capacity available to the rest of your traffic.

​
Polling

Use webhooks as the primary status signal. If you also poll:
  1. Read the normal payment or payout endpoint first.
  2. Poll no faster than once every five seconds for a non-final transaction.
  3. Add random jitter and increase the interval after repeated unchanged responses.
  4. Stop polling when the transaction reaches a final status.
Use requery, sync and inspect only for recovery or diagnostics. They are not the normal status-reading path.

​
Rate-limit responses

When a limit is exceeded, the API returns 429 Too Many Requests with these headers: Respect Retry-After when it is present. Otherwise, retry with exponential backoff and jitter. Never run parallel retry loops for the same transaction.