# Rate limits

> The request limits per IP address, user and API key, how a 429 answers, and how to back off.

Source: https://docs.nexafone.so/v1/rate-limits/

Nexafon limits requests per **IP address**, per **signed-in user** and per **API key**, with a sliding window (GCRA).
Every operation belongs to a class; most are `standard`, and a few that create credentials or touch money are
`sensitive` (creating keys, inviting members, creating webhook endpoints, saving a PayPoint key). The limits, generated
from the backend:

| Class | Counted | Rate | Burst |
| --- | --- | --- | --- |
| sensitive | Per IP address | 20 per minute | 20 |
| sensitive | Per API key | 60 per minute | 60 |
| sensitive | Per signed-in user | 20 per minute | 20 |
| standard | Per IP address | 600 per minute | 600 |
| standard | Per API key | 1200 per minute | 1200 |
| standard | Per signed-in user | 600 per minute | 600 |

The SDK session exchange counts against the publishable key once the request has proved it comes from the key’s
allowed origin.

## When you hit a limit

The API answers `429 Too Many Requests` with the code [`rate_limited`](/v1/errors/rate_limited/) and a `Retry-After`
header in seconds:

```http
HTTP/1.1 429 Too Many Requests
Retry-After: 12
Content-Type: application/problem+json

{"type": "https://docs.nexafone.so/errors/rate_limited", "title": "Too Many Requests", "status": 429, "code": "rate_limited", "detail": "Too many requests. Try again later."}
```

Wait at least `Retry-After` seconds, then retry; with several workers, add jitter. Send writes with an
[`Idempotency-Key`](/v1/api/#idempotency) so retries are safe.

## WhatsApp’s own limits

WhatsApp limits how many messages and calls a number may send; Nexafon passes those on as `whatsapp.*` codes, such as
`whatsapp.throughput_limited` or `whatsapp.business_call_limit`. They are listed in the [error catalog](/v1/errors/).