RPM to RPS Converter (API Rate Limit Calculator)
Convert RPM to RPS instantly (and RPH/RPD). RPS = RPM ÷ 60. Free API rate-limit calculator with a quick reference table and real provider limits.
See step-by-step calculation
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
RPM → RPS Quick Reference: Common API Rate Limits
| 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 |
Fuente: documentación oficial de cada proveedor (OpenAI, GitHub, Google, Twitter/X, Stripe, Twilio), publicada en 2024–2025. Conversión: RPS = RPM ÷ 60 = RPH ÷ 3,600; RPD = RPS × 86,400.
How it works
How to convert RPM to RPS
All four units describe the same throughput, just over different time windows, so every conversion is exact and linear. The one most people need:
RPS = RPM ÷ 60 # requests per minute → requests per second
RPM = RPS × 60 # requests per second → requests per minuteThe full chain across every unit:
RPS = RPM ÷ 60 = RPH ÷ 3,600 = RPD ÷ 86,400
RPM = RPS × 60 = RPH ÷ 60 = RPD ÷ 1,440
RPH = RPS × 3,600 = RPM × 60 = RPD ÷ 24
RPD = RPS × 86,400 = RPM × 1,440 = RPH × 24(86,400 comes from 60 s × 60 min × 24 h = the number of seconds in a day.)
Minimum inter-request delay (the value you actually plug into a throttling loop):
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---
RPM → RPS quick conversion table
| RPM (per minute) | RPS (per second) | Min. delay between calls | RPD (per day) |
|---|---|---|---|
| 10 RPM | 0.17 RPS | 6 s | 14,400 |
| 30 RPM | 0.50 RPS | 2 s | 43,200 |
| 60 RPM | 1.00 RPS | 1 s | 86,400 |
| 100 RPM | 1.67 RPS | 600 ms | 144,000 |
| 120 RPM | 2.00 RPS | 500 ms | 172,800 |
| 300 RPM | 5.00 RPS | 200 ms | 432,000 |
| 500 RPM | 8.33 RPS | 120 ms | 720,000 |
| 600 RPM | 10.0 RPS | 100 ms | 864,000 |
| 1,000 RPM | 16.67 RPS | 60 ms | 1,440,000 |
| 3,000 RPM | 50.0 RPS | 20 ms | 4,320,000 |
| 5,000 RPM | 83.3 RPS | 12 ms | 7,200,000 |
---
Real-world rate limits from major API providers
Published limits (as of 2024–2025) converted to a common scale so you can compare them at a glance:
| 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) → RPS: divide by 3,600. GitHub publishes its limits in RPH.
---
Worked examples
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 averaging 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 integer division for RPS — 60 RPM ÷ 60 = 1 RPS is fine, but 61 RPM ÷ 60 truncated to 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.
Example: convert 500 RPM to RPS
Frequently asked questions
How do I convert RPM to RPS?
What is 500 RPM in RPS?
What is the difference between RPS, RPM, RPH, and RPD?
Why does a 60 RPM limit mean I must wait 1 second between requests?
How do I convert Requests per Hour (RPH) to RPS?
What HTTP status code indicates a rate limit has been exceeded?
How do I configure Nginx to enforce a rate limit of 500 RPM per IP?
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?
What is a sliding window vs. a fixed window rate limit, and does it affect conversion?
How many requests can I make per day on a 1 RPS limit?
Sources & references
Methodology & trust
Calculadora de tecnología revisada por el equipo editorial de Hacé Cuentas, contrastada con IETF RFC 6585 – Additional HTTP Status Codes (429 Too Many Requests), según nuestra política editorial y metodología.
Última revisión: June 20, 2026. Los parámetros se verifican periódicamente con las fuentes citadas.
Calculations run 100% in your browser. We do not store or transmit your data.
Indicative results. For critical decisions, consult a professional.
Rodríguez, M. (2026). RPM to RPS Converter (API Rate Limit Calculator). Hacé Cuentas. https://hacecuentas.com/rate-limit-api-rpm-rps
Contenido bajo licencia CC-BY 4.0 — reutilizable citando la fuente con enlace a Hacé Cuentas.