What Is API Rate Limiting?
Why APIs Limit How Often You Can Call Them
API rate limiting is a control that restricts how many requests a client can make to an API within a set period, such as a minute or an hour. A limit is usually tied to an API key, an account or an IP address. Requests beyond the limit are rejected or delayed.
Limits serve several purposes. They stop one heavy client from slowing the service for everyone else, they protect back-end systems such as databases from sudden spikes, and they let providers offer plans with different allowances. A limit also makes brute-force attempts, such as trying thousands of passwords in a row, much slower. Gateways often enforce limits centrally, as described in the article on API gateways.
A rate limit controls speed, while a quota is a longer allowance, such as a total per month. Many providers use both.
Common Rate-Limiting Algorithms
Providers use several methods to count requests. A fixed window counts requests in set blocks of time, such as each clock minute. It is simple, but traffic can bunch up at the boundary between two windows, letting a client send about twice the intended number of requests in a short span.
A sliding window counts requests over a moving period, which smooths out that burst. The token bucket model gives each client a bucket that refills at a steady rate up to a maximum size. Each request takes a token, so short bursts are allowed while the average rate stays controlled. The leaky bucket method works similarly but processes requests at a constant rate.
429 Responses, Headers and Retries
When a client exceeds its limit, a well-designed API responds with the status code 429 Too Many Requests. The response often includes a Retry-After header saying how long to wait before trying again. Many APIs also return headers showing the remaining allowance and when the window resets, although the names of these headers vary between providers.
Clients should respect these signals. Retrying immediately in a tight loop makes the problem worse. The usual approach is exponential backoff, which means waiting longer after each failed attempt, with a small random delay so that many clients do not retry at the same moment. Caching responses and batching requests can also reduce the number of calls needed.
A Shared Hosting Monitoring Example
Imagine a web hosting company that offers an API for customers to check server status and create backups. One customer writes a script that polls the status endpoint every second for dozens of servers. Without limits, that script could slow the platform for every other customer. The provider sets a per-key limit, so the script starts receiving 429 responses once it exceeds its allowance. The customer's developers then add a delay between calls, and the platform's load stays predictable.
Frequently asked questions
Which status code does an API return when rate limited?
The standard response is 429 Too Many Requests, which tells the client it has sent too many requests in a given period. Look for a Retry-After header, which indicates how long to wait before the next attempt. Some APIs return other codes during general overload, but 429 specifically signals a limit on this client.
Is rate limiting the same as DDoS protection?
No, though the two overlap. Rate limits apply per client, key or account to keep usage fair and predictable. DDoS (distributed denial-of-service) protection is a broader defense against floods of traffic that can overwhelm a network, and it often runs in infrastructure in front of the application. Good APIs usually use both.