HTTP 429 Too Many Requests — What It Means and How to Fix It

What causes this error

HTTP 429 is returned when a client exceeds the server's rate limit — the maximum number of requests allowed in a time window (e.g., 100 requests per minute per API key). Rate limits operate at different levels: per IP, per API key, per user, per endpoint, or globally across the service. Third-party APIs (OpenAI, Stripe, Twilio) have tiered limits by plan.

How to fix it

1. 01

   step 1

   Read the Retry-After header and wait before retrying

   RFC 6585 defines `Retry-After` as either a number of seconds to wait or an HTTP-date timestamp. Never retry immediately after a 429 — it guarantees more 429s. Wait for the window to reset.

   async function fetchWithRateLimit(url, options) {
     const res = await fetch(url, options)
     if (res.status === 429) {
       const retryAfter = res.headers.get('retry-after')
       const waitMs = retryAfter ? parseInt(retryAfter) * 1000 : 60_000
       console.log(`Rate limited. Waiting ${waitMs}ms...`)
       await new Promise(r => setTimeout(r, waitMs))
       return fetchWithRateLimit(url, options)  // retry once
     }
     return res
   }

   Copy
2. 02

   step 2

   Implement exponential backoff with jitter

   Exponential backoff prevents thundering herd: all clients retrying at the same time and re-triggering the rate limit. Add random jitter to spread retries across the window.

   async function fetchWithBackoff(url, options, attempt = 0) {
     const res = await fetch(url, options)
     if (res.status === 429 && attempt < 5) {
       const base = Math.min(1000 * 2 ** attempt, 30_000)  // cap at 30s
       const jitter = Math.random() * 1000                 // up to 1s random
       await new Promise(r => setTimeout(r, base + jitter))
       return fetchWithBackoff(url, options, attempt + 1)
     }
     return res
   }

   Copy
3. 03

   step 3

   Track X-RateLimit-Remaining and slow down proactively

   Don't wait for a 429. Read `X-RateLimit-Remaining` on every response. When it approaches zero, add a delay before the next request. This avoids hitting the limit in the first place.

   async function apiCall(url) {
     const res = await fetch(url, { headers: { Authorization: `Bearer ${API_KEY}` } })
     const remaining = parseInt(res.headers.get('x-ratelimit-remaining') ?? '100')
     const reset = parseInt(res.headers.get('x-ratelimit-reset') ?? '0')
     if (remaining < 5) {
       const msUntilReset = (reset * 1000) - Date.now()
       if (msUntilReset > 0) await new Promise(r => setTimeout(r, msUntilReset))
     }
     return res
   }

   Copy
4. 04

   step 4

   Batch requests or use bulk endpoints

   If you're calling an API in a loop (e.g., enriching 10,000 records one by one), switch to bulk endpoints. Most APIs that rate-limit individual calls offer a batch endpoint that processes many items per request, dramatically reducing call count.

   // Instead of 10,000 individual calls:
   for (const id of ids) await fetch(`/api/users/${id}`)  // 10,000 requests
   
   // Use a bulk endpoint:
   const chunks = chunk(ids, 100)  // split into groups of 100
   for (const group of chunks) {
     await fetch('/api/users/batch', { method: 'POST', body: JSON.stringify({ ids: group }) })
     await new Promise(r => setTimeout(r, 1000))  // pace between batches
   }

   Copy
5. 05

   step 5

   Cache responses to reduce repeat calls

   Many 429 situations arise from fetching the same data repeatedly. Add a short-lived cache (even 60 seconds) for idempotent GET requests. For user-facing apps, deduplicate concurrent requests with a request deduplication layer.

   const cache = new Map()
   async function cachedFetch(url, ttlMs = 60_000) {
     const cached = cache.get(url)
     if (cached && Date.now() - cached.ts < ttlMs) return cached.data
     const data = await fetch(url).then(r => r.json())
     cache.set(url, { data, ts: Date.now() })
     return data
   }

   Copy

How to verify the fix

• `X-RateLimit-Remaining` stays above 0 during normal operation.
• Retry logic correctly waits for `Retry-After` before retrying.
• No burst of parallel requests — use a queue with concurrency limit.