An API returns 429 Too Many Requests. Immediately repeating the request may worsen the situation. First inspect the documented limit and any waiting information in the response.

A simplified example is:

HTTP/1.1 429 Too Many Requests
Retry-After: 120

Here the header expresses seconds. It may also contain an HTTP date. Handle the actual format instead of blindly interpreting every value as a number.

Not every operation should be retried

Distinguish read requests from writes. An uncertain write outcome can produce duplicate effects when repeated without an appropriate API contract. The response class alone does not resolve that business question.

For retryable work, define a bounded policy covering attempts, waiting and visible failure. Avoid endless loops. Processes sharing a limit should not all resume simultaneously.

Test against an isolated service deliberately returning 429. Verify waiting, termination after the chosen limit and truthful failure reporting. After termination, leave the action available for another attempt and show the reason.

Record ownership of the affected account and quota. Raising a limit can involve costs or provider terms, which is a separate decision from implementing error handling.

Sources