Give it the published limit — say 1000 per hour — and it works out the rate in every other period, the gap you need between requests to stay under it, token bucket settings, the share each client gets, and a retry schedule for when you hit a 429 .
Send no faster than
1 request every 4.00 s
0.2500 req/s · 90% of 1,000 per hour
The Same Limit, Other Periods
| Window | Limit | Target (90%) | Spare |
|---|---|---|---|
| second | 0.2778 | 0.2500 | 0.0278 |
| minute | 16.7 | 15 | 1.67 |
| hour | 1,000 | 900 | 100 |
| day | 24,000 | 21,600 | 2,400 |
Min Spacing
4.00 s
between requests
Headroom
100
requests per hour spare
Per Client
0.2500
req/s across 1 client
Window Refill
12.0 s
to refill a full bucket
Token Bucket (sized for a 10-second burst)
Capacity
3 tokens
Refill rate
0.2500 tokens/s
Max burst
3 requests
A client that has been idle can fire 3 requests at once, then drops to 0.2500 req/s. Refilling an empty bucket takes 12.0 s.
Retry Schedule (after a 429, doubling, capped at 5 min)
Honour the server's Retry-After header when it sends one. Add jitter — pick a random wait between zero and the figure above — or every client that got throttled together will retry together.