Stripe 429 Too Many Requests: backoff properly instead of hammering

TL;DR: Find the hot path: check which code path spiked (list calls in a loop, N+1 API calls in a webhook handler, a migration script with no throttle). ## The fix Immediate: back off with exponential delay and jitter. # Stripe 429 Too Many Requests: backoff properly instead of hammering ## The symptom HTTP 429

Stripe 429 Too Many Requests: backoff properly instead of hammering

The symptom

HTTP 429 responses from the Stripe API, SDK raising rate-limit errors. Usually appears as a burst: a deploy, a backfill script, or a webhook handler that calls the API per event.

Confirm the cause

Stripe measures rate limits in requests per second per account, with extra per-endpoint limits on some operations. A 429 means you exceeded them. Find the hot path: check which code path spiked (list calls in a loop, N+1 API calls in a webhook handler, a migration script with no throttle).

The fix

Immediate: back off with exponential delay and jitter. Respect any Retry-After header. Never retry a 429 immediately in a tight loop; that is how a brief spike becomes a sustained outage.

SDK knobs: the official SDKs retry automatically with maxNetworkRetries (default 2 in most SDKs). For batch jobs, raise it and add your own throttle between calls. For webhook handlers, do the minimum work synchronously (verify, enqueue, return 200) and move Stripe API calls to a background worker.

Structural: the most common fix is not better retries but fewer calls:

• Expand nested objects (expand: ['customer']) instead of fetching them separately.
• Cache prices, products, and coupons; they barely change.
• Use webhooks to maintain local state instead of polling list endpoints.
• For data migrations, throttle to a fixed requests-per-second budget well under the limit.

Verify the fix

Re-run the offending job against test mode and confirm zero 429s in the logs. Load-test the webhook handler at 2x expected peak event rate and confirm p99 latency stays flat. Set an alert on 429 rate so the next spike pages someone before customers notice.

When to use

You hit exactly this: Stripe 429 Too Many Requests: backoff properly instead of hammering in Stripe 429 Too Many Requests.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Stripe 429 Too Many Requests.

Stripe's rate limit documentation states that exceeding limits returns HTTP 429 Too Many Requests, that limits are measured in requests per second per account with additional per-endpoint limits, and advises treating limits as maximums and avoiding unnecessary load (docs.stripe.com/rate-limits).