HTTP 429 Too Many Requests in fetch

What a 429 response means

RFC 6585 defines 429 Too Many Requests: you sent too many requests in a given amount of time. The response should explain the condition and may include a Retry-After header saying how long to wait. RFC 6585 also says a 429 must not be stored by a cache.

APIs count limits per client IP, per API key or per endpoint, depending on the API. Some signal a rate limit with 403 instead of 429; GitHub is one, covered in GitHub API rate limits.

Retry-After: seconds or an HTTP date

RFC 9110 defines Retry-After as either a number of seconds or an HTTP date. Its examples are 120 and Fri, 31 Dec 1999 23:59:59 GMT. Handle both, and clamp a date in the past to zero, since the result depends on the visitor's clock.

Cross-origin scripts can't read Retry-After by default. The Fetch standard exposes only 7 response headers to them:

• Cache-Control, Content-Language and Content-Length
• Content-Type and Expires
• Last-Modified and Pragma

Every other header, including Retry-After and X-RateLimit-*, must be listed in Access-Control-Expose-Headers. On 28 October 2026 a 429 with Access-Control-Allow-Origin but no expose list gave response.status 429 and response.headers.get('Retry-After') null in Chromium 153, Firefox 155 and WebKit 26.6 (Playwright 1.63). With Access-Control-Expose-Headers: Retry-After the same call returned "30", or the date string "Wed, 28 Oct 2026 22:19:55 GMT" for the date form.

Why fetch() reports a CORS error instead of 429

Rate limits are often enforced by a CDN or WAF in front of the API, and those 429 responses frequently lack Access-Control-Allow-Origin. The browser blocks the response, so fetch() rejects with a TypeError and your code never sees the status or Retry-After.

CoinGecko shows both shapes. api.coingecko.com/api/v3/ping answers 200 with Access-Control-Allow-Origin: *, but in a burst of 150 requests, 15 at a time, 135 answers were a 429 with a JSON error body, a Retry-After header and no CORS header at all. Another 13 were an application-level 429 with the 10-byte body Throttled, which kept Access-Control-Allow-Origin: * but exposed no headers, so its x-ratelimit-remaining: 0 stayed hidden.

Firefox and WebKit print the real status at the end of the line; Chromium's line doesn't mention it. When a call that worked a minute ago suddenly shows a CORS error in Chrome, repeat it in Firefox or Safari and look for Status code: 429 before you touch any CORS settings.

A preflight can be rate limited too: a direct OPTIONS during the burst got the same CORS-less 429. Chromium then reports Response to preflight request doesn't pass access control check, and WebKit says Preflight response is not successful. Status code: 429.

Retry with backoff that honors Retry-After

const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

function retryAfterMs(response) {
  const value = response?.headers.get('Retry-After');
  if (!value) return null;
  if (/^\d+$/.test(value)) return Number(value) * 1000;
  const date = Date.parse(value);
  return Number.isNaN(date) ? null : Math.max(0, date - Date.now());
}

async function fetchWithRetry(url, options = {}, { attempts = 5, maxDelayMs = 60_000 } = {}) {
  for (let attempt = 1; ; attempt++) {
    let response = null;
    try {
      response = await fetch(url, options);
      if (response.status !== 429 && response.status < 500) return response;
    } catch (error) {
      // A 429 without Access-Control-Allow-Origin arrives here as a TypeError
      if (error.name !== 'TypeError' || attempt === attempts) throw error;
    }
    const delay = retryAfterMs(response) ?? Math.random() * Math.min(maxDelayMs, 500 * 2 ** attempt);
    if (attempt === attempts || delay > maxDelayMs) return response;
    await sleep(delay + Math.random() * 250);
  }
}

1. Retry only what can recover

   Retry on 429, 5xx and TypeError, because a blocked 429 arrives as a TypeError. Anything else, such as an AbortError, is rethrown.

2. Use the server's wait first

   Retry-After is parsed as seconds or as an HTTP date.

3. Fall back to full jitter

   Without a readable Retry-After, wait a random time up to 500 ms times 2 to the power of the attempt, capped at maxDelayMs.

4. Spread the retries

   Every wait gets up to 250 ms of extra jitter so many clients don't retry in lockstep.

5. Give up cleanly

   When attempts run out or Retry-After asks for more than maxDelayMs, the last response is returned for your UI to handle.

On 28 October 2026, against an endpoint that answered 429 with Retry-After: 1 twice, fetchWithRetry returned the 200 on the third attempt after about 2.2 seconds in Chromium 153, Firefox 155, WebKit 26.6 and Node 22. A 429 with Retry-After: 30 and maxDelayMs of 10000 came back immediately, and a 429 without CORS headers threw the TypeError after all 5 attempts.

Retry only idempotent requests such as GET and HEAD automatically. Retrying a POST can repeat its side effect.

Rate limits through a shared CORS proxy

A CORS proxy calls the API from its own server addresses, not from each visitor's IP. An API that limits per IP therefore counts every site using that proxy together, and a proxy never raises that limit.

Through https://proxy.cors.dev/ on 28 October 2026, the iTunes Search API answered 429 with a 79-byte body naming the rate-limited bucket and the proxy's IPv6 address, with Retry-After of 12 and later 39 seconds; one retry got 403. CoinGecko /api/v3/ping answered 429 with Retry-After of 25 and later 60, and fetchWithRetry got 429 on all 5 attempts over about 100 seconds. A direct request from another IP a moment later returned 200 with Access-Control-Allow-Origin: *.

The proxy does make an upstream 429 readable: cors.dev echoes your origin, exposes Retry-After and sets X-Cors-Source: upstream. Its own free limit is about 600 requests a minute per IP (per /64 for IPv6, approximate, counted per location), and past it you get 429 with Retry-After, X-Cors-Error: rate_limited, X-Cors-Source: gateway and an X-Cors-Signup link.

If an API already sends Access-Control-Allow-Origin, as CoinGecko and GitHub do, call it directly so each visitor uses their own per-IP allowance; keep the proxy for APIs without CORS headers. cors.dev Pro at $5 a month for 500,000 requests (7-day trial with 1,000 requests, no card) allows 3,000 requests a minute per account and 100 in flight, and X-Cors-Cache: 60 can cache a GET for up to 60 seconds (the header takes 1 to 300), but only when the upstream answers 200 and its headers allow caching; a 429 is never cached. Cached responses go only to the Connection key and origin that stored them, caching is best-effort, and hits still count as requests, but repeated calls for the same URL reach the API less often.

Good questions.