The journal
How to stop 429 Too Many Requests
Practical steps to stop HTTP 429 errors now: slow down, honor Retry-After, add throttling and safe retries, and know when to contact the provider.
Slow your client down immediately. Honor any Retry-After response header, pause bursty jobs, and add throttling and exponential backoff with jitter before retrying. A 429 means you exceeded a server-defined rate limit, so spacing requests and respecting server guidance is the fix you can apply right now (MDN: 429 Too Many Requests; Postman: HTTP Error 429).
Immediate fixes that stop 429 now
Read the response and wait
Check the 429 response for a Retry-After header and wait exactly that long before trying again. If it is missing, wait with exponential backoff rather than retrying immediately (MDN; Postman).
Stop bursty clients and retries
Temporarily pause scheduled jobs, parallel workers, scrapers, or browser automations that could be flooding the endpoint. In browser flows, repeated background POSTs can trigger 429 even if a user clicks once; a Microsoft Q&A thread documents a login flow where repeated requests caused 429s until an OEM optimization app was removed (Microsoft Q&A: Browser POST 429 case). If you’re scraping, throttle requests and note that spreading traffic across IPs only helps when the site’s limit is per IP, not per key or account (Firecrawl: 429 in scraping).
If you don’t control the limit
Limits may be scoped by IP, user, application, endpoint, or globally. If you’re already pacing traffic and still getting 429s, collect timestamps and headers and contact the provider; you might be hitting a shared or account-level quota you can’t change client-side (MDN).
Make 429 rare: pacing and safe retries
Throttle and queue your calls
Implement client-side rate limiting so requests are evenly spaced. Use a small request queue to smooth bursts, and cache GET responses to avoid unnecessary repeats. Where an API supports it, batch multiple lookups into a single call (Postman; Firecrawl).
Retry safely with exponential backoff and jitter
Always prefer the server’s Retry-After value. When it’s absent, use exponential backoff and add jitter to avoid synchronized “thundering herd” retries. Cap your attempts and stop when the cap is reached (Postman). For non-idempotent operations, use idempotency keys so a retry does not create duplicates.
Troubleshoot by likely cause
APIs and backend jobs
When multiple workers share the same API key, their combined traffic may exceed per-account or concurrent limits even if each worker seems modest. Add a central limiter, cap concurrency, and log rate-limit headers such as Retry-After, X-RateLimit-Remaining, and reset signals to understand your headroom (Postman).
Websites, CMSs, and plugins
On sites like WordPress, a noisy plugin or theme can issue frequent background requests. Disable extensions one by one to find the offender, then reduce polling frequency, add caching, or replace it (freeCodeCamp: 429 explained).
Stop 429s: a quick operator checklist
When to ask for more capacity
If you’re pacing requests, respecting Retry-After, using backoff, and still see regular 429s, the limit is likely outside your control. Contact the provider with sample request IDs, timestamps, and rate-limit headers. Explain your throttle settings and request an increase or guidance on scope (per IP, key, user, or endpoint) (MDN; Firecrawl).
FAQ
How long should I wait after a 429?
Use Retry-After if present. If it’s missing, start with a short delay and double it on each attempt with jitter, stopping after a reasonable cap (Postman).
Is it safe to retry POSTs?
Only if you implement protections. Prefer idempotent endpoints; otherwise use idempotency keys to prevent duplicate effects (Postman).
Related reading: if you’re confusing rate limits with timeouts, see What is an API timeout?
