An HTTP 429 is not an invitation to retry immediately in a tight loop. It is the server saying that work arrived faster than the current allowance. A client that retries every few milliseconds turns a temporary limit into a longer outage and makes its own queue harder to reason about.
Read Retry-After when the API provides it. If the value is a number, it is usually seconds; if it is a date, calculate the delay against a reliable clock. When the header is absent, use exponential backoff with random jitter and a strict maximum attempt count. Jitter matters when many workers were limited at the same moment, because identical delays make them collide again.
Decide which operations can be retried. A GET is normally safe. A POST that creates an order may not be unless the API supports an idempotency key. Persist that key with the job so a process restart does not generate a new one. Retrying with a fresh key defeats the protection.
Expose the wait to callers. Record the request ID, limit headers, next attempt time, and final outcome. A queue dashboard that says “scheduled for 14:32 because the provider requested a 60-second delay” is much more useful than a generic timeout. Rate limits are part of the contract, and clients are more reliable when they treat them as capacity signals rather than exceptional surprises.