Home / Knowledge hub / API rate limiting
Knowledge hub
API rate limiting
Capping how many calls a client can make so abuse and cost stay bounded.
What it means
API rate limiting caps how many requests a client may make in a set time, such as 100 calls a minute per key. When the cap is reached the API refuses further calls, usually with an HTTP 429 status, until the window resets.
The limit can be per account, per key, per address or per endpoint. A sensible design uses tighter limits where a request is expensive or sensitive, such as sign-in, password reset or sending an email, and looser ones for cheap reads.
Why it matters
Without limits, one client can slow everyone else down, run up your cloud or messaging bill, scrape your whole data set, or guess passwords at machine speed. These are quiet failures: each request looks legitimate, and the harm is in the volume.
Limits are also how you keep a promise to paying customers that their usage will not be crowded out. OWASP lists the lack of them under unrestricted resource consumption, and rate limiting on sign-in is a key defence against credential stuffing.
How it shows up
Limits sit in an API gateway, a reverse proxy or the application itself. Weak points are common: a limit that only counts per address when attackers have thousands, a limit on one route but not the equivalent route in an older version, or counters that can be reset by changing a header or the case of a username.
Return clear 429 responses with a Retry-After header so honest clients can back off. Test by sending bursts to sign-in, reset, search and export routes, and see whether the limit holds across versions, methods and accounts. Pair with limits on page size and payload size.
Questions people ask
API rate limiting, answered
What status code should a rate-limited API return?
HTTP 429 Too Many Requests, defined in RFC 6585. A Retry-After header tells the client how long to wait.
Use the same response whether the limit was hit by a person or a script.
Is rate limiting the same as throttling?
The terms overlap. Rate limiting usually refuses requests over the cap. Throttling slows them down or queues them instead.
Either can protect an API. Refusing is simpler and clearer for clients.
Does rate limiting stop denial of service?
It helps with simple floods from single clients but cannot stop large distributed attacks, which need protection at the network edge.
It does stop individual clients, buggy scripts and abusive customers from overloading you.
Which endpoints need the strictest limits?
Sign-in, password reset, one-time code checks, account creation, anything that sends a message, and anything that does costly work such as search or export.
Think about what an attacker gains from a thousand tries.
How is a rate limit bypassed?
By rotating addresses, by spreading attempts across accounts, by finding an unlimited older version of the same route, or by varying request details so the counter sees a new client.
Limit on the account and the target as well as the address.
Related
Terms that sit next to this one
Rate limiting
Capping how often something can be attempted, per user or per address.
Unrestricted resource consumption
API calls that can use unlimited CPU, memory, money or third-party credits.
Brute force
Trying passwords or codes over and over until one of them works.
Credential stuffing
Trying passwords leaked elsewhere, because people reuse them.
API abuse
Using an API as designed but at a scale or in a way that harms you.
What happens on request ten thousand?
Missing and bypassable limits are part of what we test, on sign-in, resets and costly routes, and we show the requests that got through. Findings are what we actually exploited. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.