Rate limiting

Rate limiting restricts how often a client can call an API, for example 100 requests per minute per API key. Requests over the limit are rejected until the window resets. It protects the service from overload and abuse, keeps one noisy client from starving others, and slows down attacks such as password guessing. The limit is usually tracked per API key, user, token or IP address.

Example

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30

{"error": "rate_limited", "message": "Try again in 30 seconds"}

429 Too Many Requests and Retry-After are standard HTTP. Headers that report the remaining quota, such as X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset, are a common convention but not a single standard, so check what your API documents.

Common algorithms

• Fixed window: count requests per calendar minute. Simple, but a client can send a double burst across a window boundary.
• Sliding window: count requests over the last N seconds, which smooths that boundary effect.
• Token bucket: tokens refill at a steady rate and each request spends one, which allows short bursts up to the bucket size while enforcing an average rate.

What to test

• The limit itself: send limit + 1 requests and check that exactly the extra one gets 429.
• Recovery: after Retry-After or the reset time, requests succeed again.
• Scope: one user’s or key’s traffic must not use up another’s quota. Check whether limits apply per key, per user or per IP, and whether a client can dodge them by rotating something cheap.
• Sensitive endpoints: login, password reset and OTP verification should have tighter limits than ordinary reads.
• Response format: a rejected request returns 429 with a helpful body, not a 500 or a hung connection.
• Client behaviour: your own clients back off and honour Retry-After instead of retrying in a tight loop.

Rate limits and your test suite

Parallel API tests and load tests can trip production-like limits and fail for reasons unrelated to the change under test. Use dedicated keys or raised limits in test environments, and when a load test is meant to measure capacity, make sure you are measuring the service and not the rate limiter.