Rate Limit

A rate limit is the ceiling an API places on how many requests a single account can send in a given window. When you cross it, the API stops processing new calls and returns an error until traffic drops back under the threshold. Rate limits protect the platform from overload and keep one noisy integration from degrading service for everyone else.

How Stripe's rate limits work

Stripe applies rate limits per account. In live mode the global default is roughly 100 requests per second; test mode and sandboxes run at a fraction of that, around 25 per second, so bulk scripts hit the ceiling sooner during development. Individual endpoints can also carry their own limit — commonly around 25 requests per second — independent of the global ceiling.

When you exceed the limit, Stripe returns HTTP status 429 Too Many Requests with a rate_limit error code. The response includes a Stripe-Rate-Limited-Reason header explaining which limit you tripped — for example a global-rate, endpoint-rate, or concurrency limit.

Handling a 429

• Back off and retry. Wait a short, growing interval (exponential backoff) before resending, rather than hammering the endpoint.
• Pair retries with an [idempotency key](/glossary/idempotency-key). If a write is retried after a 429, the key guarantees the operation runs at most once.
• Spread out bulk work. Queue large jobs and cap concurrency instead of firing every request at once.
• Read from [events](/glossary/event) and [webhooks](/glossary/webhook) instead of polling an endpoint in a tight loop — event-driven flows generate far fewer calls.

Why it matters

Hitting a rate limit means requests silently fail unless your code handles the 429. A reporting job that pulls thousands of charges, or a migration that creates records in a loop, is the usual culprit. Designing for backoff, caching results, and preferring webhooks over polling keeps an integration well under the limit even as volume grows.