Almost every retry helper I've reviewed had at least one of these bugs:

It retries a 400 , so a bad request gets sent four times instead of once.

It ignores Retry-After and hammers a server that already told it when to come back.

It has no timeout, so one hung connection blocks the whole job.

Every client waits exactly the same time, so they all come back at the same moment and trigger the next 429.

The reason these survive is that retries are hard to test. Your real API rarely fails on demand. So I added failure endpoints to testingapis.com (a free fake API I build) and used them to check my own helper. Here's the helper and what happened.

What to retry

Status Retry? Why

408, 429 Yes The server asked you to slow down or try again

500, 502, 503, 504 Yes Usually temporary

Network error, timeout Yes The request may never have arrived

400, 401, 403, 404, 422 No Sending it again gives the same answer

One warning: retrying a POST that timed out can create the order twice.…