10 API Rate-Limiting Strategies for Reliable Web Applications
Ten rate-limiting strategies for your own APIs, from token buckets and sliding windows to per-operation and cost-based limits, and how to signal them.
Which rate-limiting strategy should an API use?
Most APIs combine a token bucket or sliding-window limit per client identity with stricter limits on sensitive operations (login, one-time passwords, password resets), weighted limits for expensive requests, plan-based quotas for paying customers, and caps on payload size and page size. Reject excess requests with a 429 status and a Retry-After value, enforce limits centrally so every server instance agrees, and monitor who hits them.
This list is for developers and technical leads building APIs for web apps, mobile apps or partners. Rate limiting protects availability and cost; OWASP's API Security Top 10 (2023) lists unrestricted resource consumption as a top API risk and recommends rate limits, per-operation throttling, payload limits and spending limits. For consuming other people's rate-limited APIs, see integration failure scenarios.
Algorithms
1. Fixed window. Count requests per client in fixed periods (for example, per minute) and reset at the boundary. Simple and cheap to store. Trade-off: clients can send a burst at the end of one window and the start of the next, briefly doubling the rate.
2. Sliding window. Count requests over the last N seconds at any moment, usually approximated by weighting the current and previous windows. Trade-off: slightly more computation, but smoother than fixed windows and avoids boundary bursts.
3. Token bucket. Each client has a bucket that refills at a steady rate up to a maximum; each request spends a token. It allows short bursts up to the bucket size while enforcing an average rate, which suits real user behaviour. Trade-off: you must choose both a refill rate and a burst size.
4. Leaky bucket or queueing. Requests enter a queue processed at a fixed rate; excess requests wait or are dropped. Useful for smoothing traffic to a fragile downstream system. Trade-off: adds latency, and queued requests can time out on the client side.
Who and what to limit
5. Per identity, not just per IP address. Limit by user, API key or tenant where you can identify them; fall back to IP address for unauthenticated traffic. IP-only limits punish many users behind one office or mobile network, and are easy to evade with many addresses.
6. Per operation for sensitive endpoints. Login, OTP verification, password reset, sign-up and payment attempts need much stricter limits than reading a product list. OWASP specifically mentions throttling operations such as OTP validation and password recovery.
7. Weighted or cost-based limits. Not every request costs the same. Give expensive operations (reports, exports, search with many filters, GraphQL queries with high complexity, calls that trigger AI models) a higher cost against the client's budget.
8. Plan-based quotas. For APIs sold to customers, combine short-term rate limits with longer-term quotas tied to their plan, and show usage in their dashboard before they hit the limit.
Enforcing and communicating limits
9. Return 429 with useful information. RFC 6585 defines 429 Too Many Requests and allows a Retry-After header saying how long to wait. Many APIs also return remaining-quota headers; the IETF is drafting standard RateLimit and RateLimit-Policy fields, which were still an Internet-Draft as of May 2026. Document your limits so client developers can build backoff and retries correctly.
10. Enforce centrally and consistently. If each server instance counts separately, a client gets a different limit depending on which server it hits. Enforce at an API gateway or edge layer, or share counters in a fast store such as Redis, and decide what happens if that store is unavailable (fail open for low-risk reads, fail closed for sensitive operations). See API gateways.
Worth noting
Rate limits are one part of resource protection. OWASP also recommends maximum payload and upload sizes, a maximum page size for list endpoints, server-side validation of parameters that control how much data is returned, and spending limits or billing alerts on third-party services your API calls.
Building an API that partners and apps depend on?
ZSpace Labs designs and builds APIs and web applications with authentication, rate limiting and monitoring planned in. See our web application development service.
Strategy comparison
| Strategy | Good for | Watch for |
|---|---|---|
| Fixed window | Simple internal limits | Bursts at window boundaries |
| Sliding window | Smoother public API limits | Slightly more state and computation |
| Token bucket | Bursty real-world clients | Choosing refill rate and burst size |
| Leaky bucket / queue | Protecting fragile downstream systems | Added latency; queued timeouts |
| Per identity | Fairness between users and tenants | Unauthenticated traffic needs IP fallback |
| Per operation | Login, OTP, password reset, payments | Locking out real users; add recovery paths |
| Weighted / cost-based | Expensive queries, exports, AI calls | Explaining costs to client developers |
| Plan quotas | Paid APIs | Visibility of usage before the limit |
| 429 + Retry-After | Well-behaved clients | Clients that ignore it; monitor them |
| Central enforcement | Multi-instance deployments | Behaviour when the counter store fails |
Common mistakes
- Setting limits without looking at real traffic; start from measured usage and leave headroom.
- One global limit for all endpoints, which is either too loose for login or too tight for reads.
- Returning 500 or 403 instead of 429, so clients cannot tell they should slow down.
- Not documenting limits, which leads to aggressive client retries that make things worse.
- Never reviewing who hits limits: a sudden rise can signal abuse, a broken client or a plan that no longer fits.
- Rate limiting without monitoring and alerting. See application monitoring.
Conclusion
Good rate limiting is layered: a fair per-identity limit using a token bucket or sliding window, tighter limits on sensitive operations, weighted limits for expensive work, plan quotas where you sell access, and clear 429 responses with Retry-After. Enforce it centrally, document it, and watch the numbers. It sits alongside the other controls in API security best practices.
Sources
IETF RFC 6585 (429 Too Many Requests) and RFC 9110 (Retry-After). IETF HTTPAPI working group, RateLimit header fields for HTTP (draft-ietf-httpapi-ratelimit-headers-11, May 2026). OWASP API Security Top 10 2023, API4 Unrestricted Resource Consumption. Accessed 28 October 2026.
Common questions.
429 Too Many Requests, defined in RFC 6585. The response can include a Retry-After header telling the client how long to wait before trying again.