API Rate Limit Calculator
An API rate limit defines how many HTTP requests a client can make to a server within a specific time window. This calculator converts between the three most common rate-limit units: Requests per Second (RPS), Requests per Minute (RPM), and Requests per Day (RPD). Use it when integrating with third-party APIs (OpenAI, Twitter/X, Stripe, GitHub, etc.) that publish limits in one unit while your code needs another. For example, OpenAI's free tier publishes limits in RPM, but your retry logic needs RPS to set backoff intervals correctly. The core conversion is: RPS = RPM ÷ 60 = RPD ÷ 86,400.
When to use this calculator
- Setting the correct Thread.sleep() or asyncio delay in a polling loop so your app never exceeds a third-party API's published RPM quota
- Calculating how many parallel workers or goroutines you can spin up before hitting a per-key RPS ceiling on services like Google Maps or Stripe
- Estimating daily API budget consumption (RPD) against a monthly request quota to avoid overage charges on pay-per-use APIs like OpenAI or AWS
- Configuring Nginx's limit_req_zone or an API Gateway throttling policy—both require a RPS (requests/second) value—when your SLA is documented in RPM
- Debugging 429 Too Many Requests errors by converting the Retry-After header value and the published rate limit to a common unit for comparison
Example Calculation
- 60 RPM
- 1 RPS
How it works
3 min readHow It's Calculated
All three units describe the same throughput, just over different time windows. The conversions are exact and linear:
# Given an input value V in unit U:
If U = RPS:
RPS = V
RPM = V × 60
RPD = V × 86,400 # 60 s × 60 min × 24 h = 86,400 s/day
If U = RPM:
RPS = V ÷ 60
RPM = V
RPD = V × 1,440 # 60 min × 24 h = 1,440 min/day
If U = RPD:
RPS = V ÷ 86,400
RPM = V ÷ 1,440
RPD = VMinimum inter-request delay (useful for throttling loops):
delay_seconds = 1 / RPS # e.g., 1 RPS → 1.0 s between calls
delay_ms = 1000 / RPS # e.g., 10 RPS → 100 ms between calls---
Reference Table
Real-world rate limits published by major API providers (as of 2024–2025):
| API / Provider | Tier / Plan | Published Limit | RPS equiv. | RPD equiv. |
|---|---|---|---|---|
| OpenAI GPT-4o | Free (Tier 1) | 500 RPM | 8.33 RPS | 720,000 RPD |
| OpenAI GPT-4o | Tier 2 | 5,000 RPM | 83.3 RPS | 7,200,000 RPD |
| OpenAI Whisper | Tier 1 | 50 RPM | 0.83 RPS | 72,000 RPD |
| GitHub REST API | Authenticated | 5,000 RPH | 1.39 RPS | 120,000 RPD |
| GitHub REST API | Unauthenticated | 60 RPH | 0.017 RPS | 1,440 RPD |
| Google Maps JS | Standard | 100 RPS | 100 RPS | 8,640,000 RPD |
| Twitter/X API v2 | Free | 1,500 RPM (read) | 25 RPS | 2,160,000 RPD |
| Stripe API | Live mode | 100 RPS | 100 RPS | 8,640,000 RPD |
| Stripe API | Test mode | 25 RPS | 25 RPS | 2,160,000 RPD |
| Twilio REST | Default | 100 RPS | 100 RPS | 8,640,000 RPD |
> RPH (Requests per Hour) = RPM ÷ 60 × 1h. GitHub publishes limits in RPH; divide by 3,600 for RPS.
---
Typical Cases
Case 1 — OpenAI free tier integration (500 RPM)
Your chatbot uses the GPT-4o free tier: 500 RPM limit.
If your app makes 1 request per user page load and expects 10,000 daily active users with an average of 5 pages each = 50,000 daily requests — well within the 720,000 RPD budget, but you still need the 120 ms delay to avoid bursting.
Case 2 — GitHub unauthenticated scraper (60 RPH)
GitHub's unauthenticated limit is 60 RPH.
Simply adding a personal access token bumps this to 5,000 RPH (83.3 RPM, 1.39 RPS, 16× faster).
Case 3 — Nginx rate limiting for an internal API (120 RPM target)
Your internal microservice SLA says "max 120 RPM per user."
limit_req_zone $binary_remote_addr zone=api:10m rate=2r/s; burst=10 nodelay allows short spikes of up to 10 extra requests before the 429 kicks in.---
Common Mistakes
1. Treating RPM as RPS — The most frequent bug. A 60 RPM limit is only 1 RPS, not 60. Setting a 1-second loop that fires 60 requests in the first second will immediately trigger a 429.
2. Ignoring burst vs. sustained limits — Many APIs (e.g., Stripe) allow short bursts above the stated RPS but enforce the limit over a sliding window. A sustained 100 RPS over 10 seconds will be blocked even if each individual second looks fine on average.
3. Using floor division for RPS — Calculating 60 RPM ÷ 60 = 1 RPS is fine, but 61 RPM ÷ 60 = 1 RPS loses the fractional part. Always use floating-point division; the true value is 1.0167 RPS (delay ≈ 983 ms).
4. Forgetting that RPD limits are calendar-day windows — A 1,000 RPD quota resets at midnight UTC (or the API's local timezone), not 24 hours after your first call. Sending all 1,000 requests at 11:55 PM leaves you with zero quota for the next 5 minutes.
5. Not accounting for concurrent threads multiplying the rate — If you run 4 parallel threads each making 1 RPS, your effective rate is 4 RPS against the API's shared per-key limit.
---
Related Calculators
There are no related calculators configured for this tool yet. Check back soon for links to bandwidth and latency calculators on hacecuentas.com.
Frequently asked questions
What is the difference between RPS, RPM, and RPD?
All three measure the same thing—API request throughput—over different time windows. RPS (Requests per Second) is used in low-latency systems and server configs like Nginx. RPM (Requests per Minute) is the most common unit in API documentation (OpenAI, Stripe). RPD (Requests per Day) governs quota-based billing windows. The relationships are exact: 1 RPS = 60 RPM = 86,400 RPD.
Why does a 60 RPM limit mean I must wait 1 second between requests?
60 RPM ÷ 60 seconds = 1.0 RPS, which means exactly one request is allowed per second on average. Sending two requests within the same second exhausts two seconds' worth of quota simultaneously, triggering a 429 Too Many Requests response. The safe inter-request delay is always 1 ÷ RPS seconds — in this case, 1.0 s.
How do I convert Requests per Hour (RPH) to RPS?
Divide by 3,600 (the number of seconds in one hour). For example, GitHub's authenticated limit of 5,000 RPH = 5,000 ÷ 3,600 ≈ 1.39 RPS, meaning a safe delay of about 720 ms between requests. To get RPM from RPH, divide by 60: 5,000 RPH ÷ 60 = 83.33 RPM.
What HTTP status code indicates a rate limit has been exceeded?
RFC 6585 standardized HTTP 429 Too Many Requests for rate limit violations. The response typically includes a Retry-After header (in seconds) or X-RateLimit-Reset (UNIX timestamp). Some older APIs incorrectly return 503 Service Unavailable or 403 Forbidden instead, so always check the API's documentation.
How do I configure Nginx to enforce a rate limit of 500 RPM per IP?
Convert 500 RPM to RPS first: 500 ÷ 60 ≈ 8.33 RPS. Then use Nginx's limit_req module: limit_req_zone $binary_remote_addr zone=myapi:10m rate=8r/s; and apply limit_req zone=myapi burst=20 nodelay; in your location block. The burst parameter absorbs short spikes (up to 20 extra requests) without immediately returning 429.
Does running multiple API keys multiply my effective rate limit?
Yes, if each key has an independent per-key limit. For example, if one OpenAI API key has a 500 RPM limit, using 4 keys in round-robin gives you an effective 2,000 RPM (33.3 RPS) throughput. However, some providers enforce organization-level or IP-level caps in addition to per-key limits, so check the API's terms of service before key-pooling.
What is a sliding window vs. a fixed window rate limit, and does it affect conversion?
The conversion math (RPS ↔ RPM ↔ RPD) is the same regardless of window type. However, behavior differs: a fixed window resets at a fixed clock interval (e.g., every minute at :00), so you can burst twice the limit across a reset boundary. A sliding window tracks the last N seconds continuously, enforcing a stricter sustained rate. Most modern APIs (Stripe, OpenAI) use sliding windows — plan your delays accordingly.
How many requests can I make per day on a 1 RPS limit?
1 RPS × 60 s/min × 60 min/h × 24 h/day = 86,400 RPD. This is a hard mathematical ceiling assuming 100% uptime with no gaps. In practice, network latency, retries, and downtime reduce effective throughput to 70–90% of the theoretical maximum, so real-world sustained throughput for a 1 RPS limit is typically 60,000–78,000 requests/day.