# Rate limits

120 requests per minute per key, the RateLimit headers and how to back off.

Each clinic key may make **120 requests per minute**, counted in a fixed window (the clock minute) and shared by every endpoint. This page shows how to read the limit and what to do when you hit it.

## Headers on every response

Every response to a valid key, errors included, carries the state of the window, so you do not have to count on your side:

```http Headers
RateLimit-Limit: 120
RateLimit-Remaining: 116
RateLimit-Reset: 36
```

| Header | Meaning |
| --- | --- |
| `RateLimit-Limit` | Requests allowed in the window. |
| `RateLimit-Remaining` | Requests left in the current window. |
| `RateLimit-Reset` | Seconds until the current window ends. |

A 401 carries none of them (there is no key to count against). When the counter is briefly unavailable the request goes through without them.

## When you hit the limit

Request number 121 of a minute answers **429** with `Retry-After: 60`, a full window. `RateLimit-Reset` has the exact seconds left, so waiting that long is enough.

```json 429 Too Many Requests
{
  "error": "przekroczono limit 120 zapytań/min"
}
```

## Feedback has its own hourly limit

[POST /feedback](https://pozyskajpacjenta.pl/docs/reference/feedback/send-feedback) also allows 20 remarks per hour per clinic, counted separately for each source, so a loop of browser error reports cannot block other remarks. Over it you get 429 with `code: "feedback_rate_limited"` and a `Retry-After` of up to an hour.

## Stay under the limit

- Cache GET responses: they carry `Cache-Control: private, max-age=60`, so a minute of caching per key on your server is safe. Free slots are the exception (`no-store`).
- Render pages at build time or with a cache in front, not on every visit.
- Back off on 429 and retry after `Retry-After` or `RateLimit-Reset`, with a little jitter when several workers share the key.