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

# Rate limits

> Global and sensitive-endpoint request limits.

The REST API has a global per-client-IP backstop. The production example sets `RATE_LIMIT_MAX=200` and `RATE_LIMIT_WINDOW=60000` (200 requests per minute); operators can change both within the validated deployment range.

Sensitive handlers add stricter Redis-backed fixed windows per IP and route. Current examples include:

| Operation                         | Limit | Window   |
| --------------------------------- | ----- | -------- |
| Public checkout creation          | 12    | 1 minute |
| Public order-status lookup        | 30    | 1 minute |
| Nickname-change code request      | 5     | 1 minute |
| Nickname-change code verification | 10    | 1 minute |
| Voucher redemption                | 8     | 1 minute |
| Voucher existence check           | 20    | 1 minute |
| Discount validation/check         | 30    | 1 minute |
| API-key creation                  | 10    | 1 minute |
| Payment session mutation          | 15    | 1 minute |
| Public analytics beacon           | 60    | 1 minute |

Authentication routes have separate brute-force throttling. Payment webhooks use a provider/shop flood guard while retaining the provider's retry semantics.

When a limit is exceeded, the API responds with `429 Too Many Requests`. Clients must back off and should add jitter instead of retrying immediately.

<Note>
  Redis shares sensitive-endpoint counters across API instances. If Redis is temporarily unavailable, each instance keeps a bounded in-memory fallback so brute-force protection is not disabled; counters are then conservative per instance until Redis recovers.
</Note>

The game plugin does not poll REST. Its Socket.IO connection and event handlers have their own authentication, validation, debounce, and event-specific rate limits.