API Rate Limit Calculator
API quota verdict, safe pace, and time to limit.
What it does
Rate limits turn API speed into budget math: every endpoint grants a quota per window, and 429 errors bill the overage in failed calls. Pacing under the line keeps integrations quiet.
The tool above takes quota, window minutes, and planned pace. It returns the fits verdict, a 90% safe pace, and minutes to exhaustion.
The default 1000 per 60 minutes allows 16.7 per min, so a 10 per min plan fits with a 15 safe pace and 100 minutes to the line. The hot case of 200 per min against 100 per min trips exceeds with half a minute to go.
IETF RateLimit headers publish quota, remaining, and reset so clients can run this exact division live. MDN documents the 429 response with Retry-After as the polite back off.
Design for the limit, not the average: queue bursts, cache repeats, and let Retry-After steer retries. Monitoring the remaining header beats discovering the wall at 2 a.m.
How to use
- Type the quota requests.
- Type the window minutes.
- Type the planned per minute pace.
- Read fits or exceeds first.
- Read safe pace beside it.
- Read minutes to limit last.
Formula
- quota
- Requests allowed per window.
- window
- Window length in minutes.
- planned
- Planned requests per minute.
IETF RateLimit header fields standardize quota, remaining, and reset reporting around the same per window arithmetic. MDN documents 429 Too Many Requests with Retry-After as the back off signal. The 90% pacing line is engineering headroom, not protocol law.
Worked example
Example: 1000 per hour quota
Defaults: 1000 per 60 min, plan 10/min.
- Quota: 1000 requests per 60 min window.
- Allowed: 1000 / 60 = 16.7 per min.
- Plan: 10 per min sits under allowed.
- Safe: floor(16.7 x 0.9) = 15 per min.
- Exhaust: 1000 / 10 = 100 min to limit.
- Tool shows Fits the quota, Safe pace 15/min, 100 min to limit.
Reference table
| Quota and plan | Allowed | Verdict |
|---|---|---|
| 1000/60 min, plan 10 | 16.7/min | Fits, 100 min left |
| 100/1 min, plan 200 | 100/min | Exceeds, 0.5 min left |
| 5000/60 min, plan 60 | 83.3/min | Fits, 83.3 min left |
| 60/1 min, plan 60 | 60/min | Fits, 1 min left |
Limits
- Single window math; stacks need each checked.
- Clock skew and shared quotas shift lines.
- Burst allowances vary by provider.
- 90% pacing is guidance, not law.
Common mistakes
- Averaging past burst caps.
- Ignoring Retry-After seconds.
- Sharing one key across workers.
- Polling instead of webhooks.
- Retrying hot into 429s.
Try it yourself
Quick checks. Answers sit tucked under each question.
100 per 1 min, plan 200?
Allowed 100/min, plan 200 exceeds, 0.5 min to limit.
5000 per 60 min, plan 60?
Allowed 83.3/min, plan 60 fits, 83.3 min to limit.
Quota 0?
Quota starts at 1: enter quota from 1 up.
Questions
Allowed rate?
Quota over window sets requests per minute; plans under it fit, over it trips 429s. IETF RateLimit headers report the same math live.
Hitting 429?
Slow workers, cap concurrency, and honor Retry-After seconds instead of hammering.
Multiple windows?
Per second, minute, hour, and day windows stack: pass each one, not just the headline quota.
Bursts vs pacing?
Bursts spend quota fast then idle; pacing spreads the same count safely across the window.
Why 90% safe?
90% of allowed leaves headroom for retries and clock skew. The tool paces there.
Fewer calls?
Pollers, webhooks, and caches cut calls: fetch deltas, subscribe to events, and store repeats.