API Rate Limit Calculator

Why APIs have rate limits

Every public API enforces rate limits — and for good reason. Without limits:

• A single client could overwhelm the entire service
• “Noisy neighbors” would degrade performance for everyone
• Costs would spiral (cloud services bill per request)
• DDoS attacks would be trivial
• Free tier abuse would make business models impossible
• Quality of service couldn’t be guaranteed

Rate limiting is a fundamental requirement of any public API at scale. Major services like Twitter (X), Google Maps, OpenAI, Stripe, and AWS all use sophisticated rate limiting to protect infrastructure and ensure fair access.

How rate limits are expressed

Rate limits are typically defined as:

Requests per time window:

• “1,000 requests per hour”
• “100 requests per minute”
• “10 requests per second”
• “10,000 requests per day”

Concurrent connections:

• “Maximum 100 concurrent connections”
• Common for streaming APIs

Token-based:

• “$100 credits per month”
• Different operations consume different credit amounts
• Common for paid APIs (OpenAI, Anthropic)

Tier-based:

• Free: 100 req/hour
• Paid Basic: 1,000 req/hour
• Paid Pro: 10,000 req/hour
• Enterprise: custom

Calculating allowed usage

Daily allowance = (Rate limit ÷ Window minutes) × 1440

Example: 1,000 requests per 60 minutes = (1000/60) × 1440 = 24,000 requests/day

Other useful formulas:

Requests per second = Rate limit ÷ Window seconds Minimum spacing = Window seconds ÷ Rate limit Safe peak calls = Rate limit × 0.75 (leave 25% headroom)

Major API rate limits (as of 2024)

Common services and their tiers:

Twitter/X API:

• Free: 1,500 tweets/month
• Basic ($100/mo): 50K tweets, 1M followers searches
• Pro ($5000/mo): 1M+ tweets

Google Maps:

• Free: $200 credit/month
• Different costs per request type
• Geocoding: ~$0.005 per request

OpenAI:

• Tier 1: 500 req/min, $100/month limit
• Tier 5+: 30,000 req/min
• Token-based usage limits

Stripe:

• 100 req/sec (per account)
• 1000 req/sec for premium clients
• Test mode: 25 req/sec

GitHub:

• 5,000 req/hour authenticated
• 60 req/hour unauthenticated
• 15,000 req/hour for GitHub Apps

AWS (typical limits):

• S3: ~3500 PUT/COPY/POST/DELETE per prefix
• DynamoDB: 1000 read units, 1000 write units typically
• Variable by service

HTTP 429 — the rate limit response

When you exceed rate limits, APIs typically respond with HTTP status code 429 Too Many Requests. The response usually includes:

Response headers:

• X-RateLimit-Limit: total requests allowed
• X-RateLimit-Remaining: requests remaining
• X-RateLimit-Reset: when the limit resets
• Retry-After: seconds to wait before retrying

Response body:

{
  "error": "Rate limit exceeded",
  "retry_after": 60
}

Smart clients parse these headers and back off accordingly.

The four request distribution patterns

Real-world API usage follows specific patterns:

Bursty / spiky:

• Sudden bursts of many requests
• Long quiet periods
• Hardest pattern to manage
• Example: monthly billing cycles, deploy spikes

Steady-state:

• Constant request rate
• Easy to manage
• Example: monitoring dashboards

Daily cycle:

• Peak during business hours
• Quiet at night
• Example: user-facing applications

Weekly cycle:

• Heavy weekdays, light weekends (B2B)
• Or opposite (consumer-facing entertainment)
• Plan capacity accordingly

Strategies to stay within limits

Request queuing:

• Use a queue (Redis, RabbitMQ) to buffer requests
• Process at controlled rate
• Smooths out traffic spikes
• Adds latency but prevents 429 errors

Caching:

• Cache API responses with TTL
• Reduces redundant identical requests
• Particularly useful for read-heavy APIs
• Examples: cache user data for 1 hour, cache weather for 15 minutes

Batching:

• Many APIs support batch endpoints
• Replace 100 individual requests with 1 batch request
• Examples:
  • Google Maps: Distance Matrix vs single requests
  • Twitter: lookup multiple tweets at once
  • GitHub: get multiple users at once

Pagination:

• Don’t request entire datasets repeatedly
• Use cursor-based pagination
• Request only changed data (delta updates)

Webhooks instead of polling:

• Many APIs support webhooks
• Service notifies you of changes
• Eliminates polling entirely
• Much more efficient

Exponential backoff for 429s:

async function fetchWithRetry(url, maxRetries = 5) {
  for (let i = 0; i < maxRetries; i++) {
    const response = await fetch(url);
    if (response.status !== 429) return response;
    const wait = Math.min(60000, 2 ** i * 1000); // 1s, 2s, 4s, 8s, 16s, 32s
    await new Promise(r => setTimeout(r, wait));
  }
  throw new Error('Max retries exceeded');
}

Off-peak scheduling:

• Run bulk operations at night
• Many APIs have higher limits during off-peak hours
• Reduces 429 risk

Optimization tips by use case

Reading user data:

• Cache aggressively (30 min - 1 hour typical)
• Use webhooks for updates
• Batch lookups when possible

Search APIs:

• Cache popular searches
• Cache results for short TTL (5-15 min)
• Implement client-side debouncing

Geocoding/mapping:

• Cache forever (geo data doesn’t change)
• Batch when possible
• Consider self-hosted alternative for high volume

Payment APIs:

• Don’t cache (security/freshness)
• Implement idempotency keys
• Use webhooks for status updates

Email/SMS:

• Use queue (process at controlled rate)
• Critical messages bypass queue
• Marketing batch sends

Real-time data:

• WebSocket vs HTTP polling
• WebSocket bypasses HTTP rate limits
• Single connection = continuous data

Rate limit algorithm types

APIs use different algorithms internally:

Fixed window:

• Counter resets at start of each window
• Simple but allows bursts at boundaries
• E.g., 100/minute resets every minute

Sliding window:

• Rolling time-based counter
• More even distribution
• More complex to implement
• E.g., 100 requests in last 60 seconds

Token bucket:

• Bucket holds X tokens
• Each request takes 1 token
• Tokens replenish at fixed rate
• Allows controlled bursts
• Most common modern algorithm

Leaky bucket:

• Queue with constant outflow rate
• Excess requests queued or dropped
• Smooths traffic

Adaptive rate limiting:

• Limits adjust based on system load
• Common in distributed systems
• Can dynamically lower limits during stress

Common rate limit mistakes

1. No retry logic: failing on first 429 instead of backing off
2. Aggressive retry: 429 → immediate retry → another 429
3. No queueing: peak traffic exceeds limits
4. Not parsing rate limit headers: missing the explicit guidance
5. Polling when webhooks available: wasting requests on no-change checks
6. No caching: re-fetching same data repeatedly
7. Hot-loop debugging: spinning loop hitting API repeatedly
8. No monitoring: discovering rate limits in production
9. Single API key for everything: one team’s bug breaks everyone
10. Synchronous bursts: not spacing concurrent requests

Building rate-limit-aware applications

Production-grade applications:

1. Centralized rate limit tracking: Redis or similar
2. Token bucket implementation: clean abstraction
3. Exponential backoff: with jitter (random delays prevent thundering herd)
4. Request prioritization: high-priority bypasses queue
5. Circuit breakers: stop calling broken APIs entirely
6. Monitoring/alerting: track 429 rates over time
7. Multiple API keys: distribute load across keys
8. Caching layers: Redis, Memcached, CDN
9. Rate limit-aware SDK wrappers: handle complexity once
10. Graceful degradation: serve stale cache when over limit

Bottom line

API rate limits are expressed as requests per time window (e.g., 1,000/hour). Daily allowance = (Rate limit ÷ Window minutes) × 1440. 429 status code means you’ve exceeded limits — respond with exponential backoff (1s, 2s, 4s, 8s…). Use caching (most effective), batching, webhooks instead of polling, and request queuing to stay within limits. Token bucket is the most common modern algorithm. Major APIs have tiered pricing where higher tiers offer 10-1000x higher limits. Production applications need centralized rate limit tracking, circuit breakers, and graceful degradation. Monitor 429 rates as a key SRE metric.