How to Respect Rate Limits – Practical Techniques
Learn how to stay within published limits: reading limit headers, pacing, concurrency caps, honouring Retry-After, and reducing requests entirely.
Respecting a rate limit means staying under it deliberately rather than discovering it by being refused. The techniques are straightforward; the discipline is treating the limit as a contract rather than a boundary to probe.
1. Read What the Server Tells You
Well-behaved APIs publish the state of your budget in response headers:
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1767225600
A client that reads these can slow down before exhausting the budget. Ignoring them and reacting only to 429 means every window ends in refusal.
2. Pace Rather Than Burst
A limit of 1,000 requests per hour is not permission to send 1,000 in the first minute. Fixed-window counters allow that arithmetic and most servers dislike the traffic shape.
Spread requests evenly across the window. Even spacing is gentler on the destination and produces more predictable throughput for you.
3. Cap Concurrency Separately
Rate and concurrency are different limits. A client can be well under its per-minute budget while holding far too many simultaneous connections.
Set a concurrency cap per host, not only globally, so one destination cannot absorb the whole pool.
4. Honour Retry-After
HTTP/1.1 429 Too Many Requests
Retry-After: 120
That header is an instruction. Waiting exactly the stated period is the correct behaviour; sending again immediately extends the penalty on many implementations.
Where no header is present, wait and space subsequent attempts progressively rather than looping at full speed.
5. Reduce the Requests You Need
The most effective limit management is needing fewer requests.
- Cache and use conditional requests so unchanged resources cost nothing.
- Request only the fields you need, where the API supports selection.
- Use larger pages within permitted bounds rather than many small ones.
- Deduplicate work across processes; the same URL fetched twice is waste.
- Collect at the frequency the decision requires, not the maximum permitted.
6. Distinguish the Signals
| Response | Meaning | Action |
|---|---|---|
429 with Retry-After |
Too fast | Wait exactly that long |
429 without it |
Too fast | Wait, then space attempts |
| Rising latency | Approaching capacity | Reduce concurrency now |
403 |
Policy, not pace | Stop and review terms |
7. Coordinate Across Workers
Several workers sharing an API key share its budget. Without coordination, each stays under the limit individually and together they exceed it.
A shared counter or a central token bucket is the usual answer, and it is the difference between a limit respected and a limit repeatedly hit.
8. Summary
Respecting rate limits means reading the budget headers, pacing evenly across the window, capping concurrency per host, honouring Retry-After exactly, and coordinating shared budgets across workers.
The largest gains come from needing fewer requests at all — caching, field selection, and collecting at the frequency the decision actually requires.