A 429 response means the caller has sent too many requests for the service's current limit. Retrying immediately from every open screen can make the problem worse.
Treat rate limiting as a distinct state in your API client. It is different from a missing record, an invalid key, or a network timeout.
Coordinate the slowdown
If the response provides a documented retry delay, use it. Read the provider's format rules rather than assuming every value is a number of seconds. Keep a retry deadline in one shared client so several components do not restart the same work independently.
Delay optional requests first. Suggestions, background refreshes, and additional result pages can usually wait. Keep already loaded content visible while explaining that another request needs a pause.
Limit retry attempts. If a request still cannot complete, offer a deliberate retry action after the pause instead of keeping an invisible loop running forever. For writes, also consider whether retrying the operation is safe under the API's semantics.
Find the source of excess traffic
Compare request counts by endpoint category and application action. A search screen may be sending a request on every render, or a home page may load identical metadata from several components. Fixing that cause is more useful than merely increasing a delay.
Test multiple tabs or devices using controlled credentials. A limit may apply to a wider boundary than one browser component, so do not present a local countdown as a guaranteed server reset unless the contract says so.
Your message can be simple: the app needs to wait before trying again. Behind that message, keep the retry policy bounded, shared, and observable without logging secret headers.