Rate limiting restricts how many requests a client, identified by IP address, API key or account, may make within a period. Requests over the limit are delayed or rejected, typically with 429 Too Many Requests.
Why it matters
It protects expensive endpoints such as login, search and APIs from brute-force attempts, scraping and runaway clients, and keeps one heavy user from degrading service for everyone. It also helps absorb small application-layer floods, though it is not a full DDoS defense.
Example
An nginx limit of 10 requests per second per IP, with a short burst allowed:
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /api/ {
limit_req zone=api burst=20 nodelay;
limit_req_status 429;
}
}By default nginx returns 503 for limited requests, so limit_req_status 429 is needed for the standard code. Well-behaved APIs also send Retry-After: 30 so clients know when to retry. Our own free API, for example, has a daily request quota described in the API docs.
Common mistakes
- Limiting by IP behind a proxy or CDN without restoring the real client IP, so everyone shares one bucket.
- Rate limiting your own uptime monitor and triggering false outage alerts. Allowlist it.
- Returning 503 or 200 with an error body instead of 429, which breaks client backoff logic.
- Applying one global limit instead of stricter limits on login and password-reset endpoints.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.