> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orqex.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate limits

> Public API quotas, polling guidance and safe retry behaviour.

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

| Operation                             |                  Limit | Scope                                         |
| ------------------------------------- | ---------------------: | --------------------------------------------- |
| Transaction creation and mutation     | 60,000 requests/minute | Per API key                                   |
| Reads served from Orqex               | 10,000 requests/minute | Per API key                                   |
| Live status and diagnostic operations |  6,000 requests/minute | Per API key                                   |
| Live status and diagnostic operations |     12 requests/minute | Per payment attempt, payment intent or payout |

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](/api-conventions#idempotency) 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](/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:

| Header                  | Meaning                                        |
| ----------------------- | ---------------------------------------------- |
| `X-RateLimit-Limit`     | Limit applied to the exhausted bucket.         |
| `X-RateLimit-Remaining` | Requests remaining in that bucket.             |
| `Retry-After`           | Seconds to wait before retrying after a `429`. |

Respect `Retry-After` when it is present. Otherwise, retry with exponential backoff and
jitter. Never run parallel retry loops for the same transaction.