Recipe

Handle rate limits gracefully

Handle the public ring’s 60/60 s limit without drama. On a 429, read Retry-After, wait that long, and retry once. Add jitter if many clients might retry together, cap exponential back-off for other transient errors, and keep steady-state traffic well under the window so you rarely see a 429 at all.

2 min read

Retry-AfterAlways honour it
jitterAvoid thundering herd
capBounded back-off

The rule for 429

A 429 carries a Retry-After header in seconds. Sleep for exactly that long, then retry the request once. Do not retry in a tight loop — that only keeps the window saturated.

Add jitter

If many clients could hit the limit at once, add a small random jitter to the wait so they do not all retry on the same tick and re-trip the limit. A few hundred milliseconds of spread is plenty.

Back off other transient errors

For 5xx responses, use exponential back-off capped at a handful of attempts (e.g. 1s, 2s, 4s, then give up). Do not retry 4xx other than 429 — those are deterministic and will fail again.

Stay under the window

Best of all, keep normal traffic well below 60 requests per 60 seconds per IP — batch, cache and debounce — and you will almost never see a 429. See the rate-limit reference.

Frequently asked questions

How long should I wait after a 429?

Exactly as long as the Retry-After header says, plus a little jitter if you run many clients. Then retry once.

Should I retry a 422 the same way?

No. A 422 is deterministic — it will fail identically. Only retry 429 and transient 5xx responses.

Funding for UK limited companies

Credicorp lends to your company, not to you personally — short-term working capital with no personal guarantee. See what your business could access.