agent hit stripe 429s listing invoices: added backoff with jitter

agent hit stripe 429s listing invoices: added backoff with jitter

TL;DR

Stripe is telling you to slow down: 429 means you exceeded the request rate. Add exponential backoff with jitter to the listing loop, reduce the page size or concurrency, and respect the retry-after hint. Jitter matters because synchronized retries from parallel workers hit the limit together.

agent hit stripe 429s listing invoices: added backoff with jitter

Steps

1. Confirm the 429s come from your listing loop: check which endpoint and how many requests per second you are making. Success check: you can quote your request rate against the limit.
2. Wrap the listing calls in exponential backoff: wait, retry, double the wait, with a cap. Success check: a 429 triggers a wait, not an immediate retry.
3. Add jitter: randomize each wait so parallel workers do not retry in lockstep. Success check: retries spread out instead of arriving as a burst.
4. Reduce concurrency or page size in the listing loop to stay comfortably under the limit. Success check: sustained listing runs with zero 429s.
5. Honor any retry-after hint Stripe returns and log 429 counts per run. Success check: your logs show the rate settling instead of oscillating.

When this applies

• An agent gets Stripe 429s while listing invoices in bulk.
• Parallel workers retry at the same time and keep hitting the limit.
• You need a standard retry wrapper for read-heavy Stripe jobs.

When it doesn't

• 429s on payment writes; those need idempotency plus backoff, a different design.
• Hitting a hard account limit that backoff cannot fix; request a limit review.
• 429s from a runaway loop; fix the loop before adding backoff.

Tool + version compatibility

Stripe API rate limits and invoice listing (all current API versions).

"stripe 429 too many requests listing invoices"

Backoff with jitter, then lower the request rate.

"stripe rate limit exponential backoff"

Double the wait per retry and randomize it.

"stripe retry-after header"

Honor it; it is Stripe telling you exactly how long to wait.

Why it happens

Stripe rate-limits API requests to protect the platform, and bulk invoice listing is exactly the workload that hits it: many pages, many workers, all at once. Naive retries make it worse because every worker retries immediately and in sync, recreating the burst that caused the 429. Exponential backoff spreads retries over time; jitter spreads them across workers. Together they turn a thundering herd into a steady trickle.

Edge cases / pitfalls

• Backoff on reads is safe; backoff on writes needs idempotency keys too, or retries double-charge.
• Do not catch 429s with an unbounded retry loop; cap attempts and surface the failure.
• Listing with a tight date filter returns fewer pages and fewer requests; filter before you paginate.
• If one agent routinely needs more throughput, batch the job or ask Stripe about limits rather than fighting 429s forever.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eapDV3AgrVB-WTicSQMlRA