What is API Rate Limiting?

Back to learning

API rate limiting controls how many requests a client can make over time. The hard part is not counting. The hard part is deciding what a "client" is when attackers rotate IP addresses and legitimate users share them.

Traditional IP-based limits still have a place, but they are weak as the main control for public APIs. A mobile carrier, office network, school, or airport Wi-Fi can put many real users behind one public IP. Blocking that IP because one session misbehaved causes collateral damage. Attackers have the opposite advantage: they can spread a credential stuffing run, scraper, or Layer 7 flood across residential proxies so no single IP crosses the threshold.

Rate Keys Matter More Than Algorithms

Token bucket, leaky bucket, fixed window, and sliding window algorithms are implementation choices. They decide how counters fill and reset. For API protection, the bigger decision is which key is being counted and which route it applies to.

A login API, search API, checkout API, and partner reporting API do not need the same policy. A route that burns CPU, calls a payment provider, or returns sensitive account data should have tighter thresholds than a low-cost public catalogue read. Rate limiting becomes useful when the key, route, interval, threshold, and action match the real risk.

Useful API rate keys include:

• API key, auth header, account ID, session ID, route, method, country, ASN, IP, TLS fingerprint, HTTP/2 fingerprint, request header combinations, response code, and bot or verified-crawler status.

These keys can be combined. For an authenticated API, grouping by Authorization header can stop one compromised or overactive client even if it uses many IP addresses. For public scraping, a TLS fingerprint plus route can identify the automation tool even while proxy exits change. For credential attacks, counting failed login response codes by fingerprint or auth context is more useful than counting all traffic from one IP.

Design Limits Around the Route

Good API rate limits start with observed traffic. How many requests does a normal client make to this route? How many failures are normal? Does usage happen in short bursts, long polling, batch jobs, or steady mobile app calls? What is the cost to origin when the route is abused?

The answer often varies by method and response. GET /api/products might allow more reads than POST /api/password-reset. A search endpoint may tolerate bursts but not repeated 404s or high-cardinality queries. A login route may allow normal retries but throttle repeated 401s tied to the same fingerprint, breached credential pattern, or proxy network.

Client communication still matters. Public APIs should return clear 429 Too Many Requests responses and, where appropriate, Retry-After or rate-limit headers. Security-driven limits may need less detail, especially when a client is probing thresholds.

A Credential Stuffing Example

Consider a login API under credential stuffing pressure. The attacker rotates through thousands of residential proxy IPs and changes user agents. An IP-only rule sees scattered traffic and does little. The application still processes password checks, origin pressure rises, and real users start seeing slow logins.

A better rule filters on the login route, counts failed responses over a longer interval, and groups by TLS fingerprint, auth header where relevant, or a combination of headers that stays stable across the tool. When the threshold is crossed, the action can move from log-only to challenge, throttle, or block. The same evidence can also trigger tighter limits on password reset and account-change routes for sessions created during the attack window.

Keep Tuning Evidence Visible

Rate limiting can be too blunt if it is deployed without feedback. Operators need allowed, blocked, and threshold-hit counters by route and key. They need to see whether a policy reduced origin pressure, whether good clients were affected, and whether attackers shifted to another route.

Peakhour's Advanced Rate Limiting model treats rate limiting as one control in the request path. Rate keys can use path, country, ASN, TLS and HTTP/2 fingerprints, headers, response codes, and bot context, while WAF, API security, and DDoS controls keep related evidence attached. The practical goal is simple: identify the actor behind the requests closely enough to stop abuse without treating every visitor, partner, or endpoint the same.