# Stripe: rate_limit (429 Too Many Requests)
> Stripe returned 429 Too Many Requests. Read the Stripe-Rate-Limited-Reason header, slow the calls, retry with backoff and stop polling the API.
Canonical: https://app369.com/fix/stripe-rate-limit-429/
Last updated: 2026-11-09
Stripe returns 429 Too Many Requests when an account sends more API calls than its rate or concurrency limit allows. In live mode the global limit is 100 requests per second, and most single endpoints allow 25. The usual cause is a loop, a backfill or polling.
**Short answer**
Check the Stripe-Rate-Limited-Reason header to see which limit you hit. Retry with exponential backoff and random jitter, make fewer calls at the same time, and replace polling with webhooks. For bulk jobs, queue the calls and run them at a steady rate.
Rather not fix it yourself? [**Stripe Billing Fix and Setup**](https://app369.com/fixed-price/stripe-billing-setup/) handles it at a fixed price, agreed before work starts.
## **Why Stripe rate limits you, and the fix**
1. 01 ### **A loop calls the API once per item**
> “If you exceed the limits, you get 429 Too Many Requests HTTP status responses.” [**Stripe, Rate limits**](https://docs.stripe.com/rate-limits) A sync job, a migration or a page that fetches every customer or invoice one by one can pass the limit fast. Use list calls with a limit and auto-pagination, store what you need in your database, and run bulk jobs through a queue at a fixed rate.
2. 02 ### **The header says which limit you hit**
> “Concurrency limits restrict the number of simultaneously active requests, separate from rate limits.” [**Stripe, Rate limits**](https://docs.stripe.com/rate-limits) The 429 response has a Stripe-Rate-Limited-Reason header: global-rate, endpoint-rate, global-concurrency or endpoint-concurrency. A rate limit means too many calls per second. A concurrency limit means too many calls running at the same time, so send fewer in parallel.
3. 03 ### **Retries fire again straight away**
> “Follow an exponential backoff schedule to reduce request volume when necessary, and add randomness to the backoff schedule to avoid a thundering herd effect.” [**Stripe, Rate limits (Handle limiting)**](https://docs.stripe.com/rate-limits) Retrying at once adds to the load. Wait longer after each 429 and add a random delay so many workers don’t retry together. Unlike rate-limit errors, lock-timeout 429s are retried by the Stripe SDKs, so add your own backoff for rate limits. When you retry a create or update call, send an idempotency key so a retry that did go through can’t charge twice.```
async function withBackoff(fn, tries = 5) {
for (let i = 0; ; i++) {
try {
return await fn();
} catch (err) {
if (err.statusCode !== 429 || i >= tries - 1) throw err;
const wait = 2 ** i * 500 + Math.random() * 500; // backoff + jitter
await new Promise((r) => setTimeout(r, wait));
}
}
}
const invoice = await withBackoff(() => stripe.invoices.retrieve(invoiceId));
// POST calls: pass { idempotencyKey } so a retried create can't run twice
const pi = await withBackoff(() =>
stripe.paymentIntents.create(params, { idempotencyKey: \`order-${orderId}\` }),
);
```
4. 04 ### **The app polls Stripe for status** Checking a payment or subscription every few seconds from each open browser adds up. Listen for webhooks such as payment_intent.succeeded or customer.subscription.updated, save the state in your database, and read it from there. In the webhook handler, use the object in the event instead of fetching it again for every event.
5. 05 ### **Search and tests have lower limits**
> “Consider Sigma or Data Pipeline for more efficient options for data-intensive analytics tasks.” [**Stripe, Rate limits**](https://docs.stripe.com/rate-limits) Sandbox allows 25 requests per second in total, and the Search API 20 reads per second, so a load test in sandbox or a search-heavy admin page can hit the limit even when live traffic doesn’t. For reporting, Stripe points to Sigma or Data Pipeline instead of the API.
6. 06 ### **lock_timeout is a different 429**
> “If you see this error intermittently, retry the request.” [**Stripe, Rate limits (Object lock timeouts)**](https://docs.stripe.com/rate-limits) A 429 with code lock_timeout means two requests touched the same object at once, such as two updates to one customer. Retry it, and make changes to one object one after another instead of in parallel.
Checked against the vendor’s docs on November 9, 2026: [Stripe docs: Rate limits](https://docs.stripe.com/rate-limits); [Stripe docs: Error codes](https://docs.stripe.com/error-codes).
## **Rather hand it over?**
Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.
- [$950**Stripe Billing Fix and Setup**Subscriptions, webhooks, customer portal and failed payments set up or fixed, tested in Stripe test mode.**See scope and start**](https://app369.com/fixed-price/stripe-billing-setup/)
- [from $450**App Fix Ticket**One reproducible bug in an existing mobile or web app, diagnosed and fixed.**See scope and start**](https://app369.com/fixed-price/flutter-firebase-bug-fix/)
- [from $450**AI-Built App Rescue**A Lovable, Bolt or Cursor app checked end to end in 3 days, then its worst problems fixed at a fixed price.****No issues worth fixing, no charge.**** If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.**See scope and start**](https://app369.com/fixed-price/ai-app-rescue/)
[**All 127 Fiverr reviews**](https://app369.com/reviews/)
Related: [**Stripe idempotency key in use**](https://app369.com/fix/stripe-idempotency-key-in-use/) · [**Stripe webhook 200 but database not updated**](https://app369.com/fix/stripe-webhook-200-but-database-not-updated/) · [**Stripe processing_error**](https://app369.com/fix/stripe-processing-error/) · [**Stripe card_not_supported**](https://app369.com/fix/stripe-card-not-supported/)
Questions
## **More on this error**
**Can Stripe raise my rate limit? **+
Stripe says to contact support to confirm the limit for a high-volume integration. Most apps that hit it fix the calling pattern instead: fewer calls, a queue and webhooks.
**Should I retry a 429 straight away? **+
No. An instant retry adds to the load that caused it. Wait longer after each 429, add a random delay, and stop after a few tries.
**Can you fix it for me? **+
If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.
A different error?
## **Describe it and get a written quote**
Send the error and what you were doing. You get a written scope, a fixed price and a timeline; Simon replies by email, usually within one business day.
[**Describe your problem **→](https://app369.com/contact/) [**All fixes**](https://app369.com/fix/)