What this tests
retry-logicheaders
Point your client at this specimen and find out — before prod does — whether it backs off, retries, and knows when to stop.
Anatomy
Stripe, to their credit, rate-limits like a gentleman: a crisp 429, a Retry-After containing an actual number, and a JSON error body polite enough to send a thank-you card to. The gentlest possible way of being told to sod off for thirty seconds — a velvet glove over a lead pipe. And yet somewhere, right now, a client is ignoring that header and hammering the endpoint like a junior SRE who's just discovered cron, converting a courteous "come back later" into a thundering herd that will eventually be written up as "upstream network instability". The client is never blamed. The client is always "upstream". If your code can't survive a rate limit delivered in a silver limousine with a complimentary mint and a signed apology, the rest of this catalogue is going to read like a coroner's report.
Replay it
curl -i https://faultydata.com/r/FD-2026-001
// response appears hereSignature
{Status:429 Headers:map[Retry-After:30 Stripe-Version:2024-06-20] Body:{"error":{"type":"rate_limit_error","code":"rate_limit","message":"Too many requests hit the API too quickly.","doc_url":"https://docs.stripe.com/rate-limits"}} Corrupt: Delay:<nil> Flaky:<nil> Sequence:<nil> Drip:<nil> StallAfter:0 Hang:false Reset:false Raw: Phases:[]}