Error 429 · server

429 Too Many Requests

In one line

You sent more requests than the server allows in a given period, so it's refusing you until the window resets.

Ben Johnson · last verified 2026-08-04

Also seen as: Too Many Requests · rate limited · 429 error

What it actually means

429 is a rate limit. Something counted your requests — by IP, by API key, or by account — decided there were too many in too short a time, and is turning you away deliberately.

This is different from 508 or 503. Those mean the server is out of capacity. 429 means the server has plenty of capacity and has decided you specifically have had enough for now.

A well-behaved 429 includes a header telling you how long to wait:

Retry-After: 60

Check for it before guessing. It’s the difference between backing off correctly and hammering a server that’s already annoyed with you.

Diagram illustrating server errors on shared web hosting.

Why it happens

An API you're calling has a rate limit

Nearly every third-party API caps requests per minute or per hour. Code that loops through records and calls an API for each one will hit this quickly.

The cap is often lower than you’d expect on free tiers — sometimes a handful of requests per second.

A security plugin is rate-limiting your visitors

WordPress firewall plugins rate-limit login attempts and sometimes normal browsing. Legitimate visitors behind a shared IP — an office, a school, a mobile carrier’s NAT — can trigger it collectively.

You're being rate-limited while developing

Refreshing rapidly while debugging, or a script in a tight loop against your own site, will trip your host’s protection. This looks alarming and is usually just you.

A crawler hit an expensive endpoint

A scraper walking every filter combination on a shop, or a search endpoint, can trigger rate limiting that then affects real visitors sharing that path.

How to fix it

1. Read the Retry-After header

curl -sI https://api.example.com/endpoint | grep -i -E 'retry-after|x-ratelimit'

Many APIs also send X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. Those tell you exactly how much budget you have left and when it resets, which is far better than guessing.

2. Back off exponentially, and respect the header

Retrying immediately makes things worse. Wait longer after each failure:

$delay = 1;
for ($attempt = 0; $attempt < 5; $attempt++) {
    $response = call_api($url);

    if ($response['status'] !== 429) {
        return $response;
    }
    // Honour the server's own instruction when it gives one
    $wait = $response['headers']['retry-after'] ?? $delay;
    sleep((int) $wait);
    $delay *= 2;   // 1, 2, 4, 8, 16
}

Note that sleeping inside a web request burns your execution time budget — see maximum execution time exceeded. For anything more than a brief retry, move the work to a background job.

3. Cache API responses

The best way to stay under a rate limit is to make fewer calls. If the data doesn’t change every second, don’t fetch it every second:

$cache = __DIR__ . '/cache/rates.json';
if (!file_exists($cache) || filemtime($cache) < time() - 3600) {
    file_put_contents($cache, call_api($url));
}
$data = json_decode(file_get_contents($cache), true);

One call an hour instead of one per visitor usually removes the problem entirely.

4. Batch requests where the API supports it

Many APIs accept multiple items in one call. Ten items in one request is one request against your limit, not ten. Check the documentation before writing a loop.

5. Whitelist yourself in your own firewall

If a security plugin is rate-limiting you while you work, add your IP to its allow-list rather than turning the protection off. Turning it off entirely and forgetting is how sites get brute-forced.

On CWP specifically

Our platform

CWP enforces a daily request cap per account — 50,000 on free plans, resetting at midnight UTC. Crossing it serves a limit page rather than your site until the reset.

Most accounts that hit it are being crawled rather than visited. Check your access logs for the top user agents before assuming it’s real traffic; blocking a scraper in .htaccess is usually the whole fix.

When this means you've outgrown free hosting

Be honest with yourself

Consistently hitting the daily request cap with genuine human traffic is a good problem and a clear upgrade signal.

Rule out bots first. In our experience the majority of accounts that hit the cap are serving crawlers, not people, and blocking a handful of user agents brings usage back under it.

Still stuck?

Post the exact error and your account name on the community forum — staff and other users answer there, and the thread helps the next person who hits this.