# Rate limits

> The request limits for clients without a key, the per-route limits and how to stay under them.

Developers · Reference · https://wxalerts.org/docs/developers/rate-limits/

Unauthenticated clients get **60 requests per minute**. Past that a client is
presumptively unreasonable and may be throttled or blocked, per
[Terms §3](/terms/#acceptable-use).

Enforcement is per source address at **120 requests a minute** (burst 60),
across every public route together, because one address behind carrier-grade
NAT or an office is many clients. Past it you get `429` with a `Retry-After`
and `RateLimit-*` headers. The gap is not headroom: 60 is still the limit your
client is held to. Send an [API key](/docs/developers/api-keys/) and the request is
charged to the key instead of your address.

A few routes that return a lot keep a tighter limit of their own, on top of
this one, whether or not a key is sent. Their pages say so.

Sixty is more than this data justifies anyway. Alerts change on the order of
minutes and the stats summary on the order of seconds, so cache what you can,
send `If-None-Match` and take the `304`, and poll on the interval your display
actually refreshes at. If you have a case for more, say hello in
[Discord](/discord/) before you start rather than after you are blocked.

Keyed API access and authenticated MQTT are governed by the API Terms in
[Terms §20 and §21](/terms/#api) and the limits set at issuance. The per-key
figure, about 300 requests a minute, and the headers every `/v1` response
carries are under [Per-key limits](/docs/developers/authentication/#per-key-limits).