If you’re running automation tools, headless integrations, or REST API workflows against your WordPress site and suddenly hitting HTTP 429 errors, you’re not alone. We see this come up regularly in our support tickets, and the cause is almost never what people expect.

Here’s a practical guide to diagnosing and fixing the problem.

What Does a 429 Error Actually Mean?

HTTP 429 is a rate-limiting response. Something between the client and your WordPress application has decided you’re making too many requests and is telling you to slow down.

The tricky part is figuring out what is returning the 429, because it could be any of several layers between your client and your WordPress installation. Before you start digging through plugin code, you need to narrow down where the response is actually coming from.

Step 1: Check Your CDN or WAF

If your site sits behind Cloudflare, Sucuri’s cloud WAF, or any other CDN with built-in security features, that’s the first place to look. These services can impose their own rate limits on API requests before traffic ever reaches your server.

Log into your CDN or WAF dashboard and check for any rate-limiting rules, bot mitigation settings, or firewall rules that might be matching your requests. In Cloudflare, for example, check under Security > WAF and Security > Rate Limiting Rules for anything targeting your /wp-json/ path.

If you find a rule that’s catching your traffic, you can either whitelist your IP, increase the threshold, or add a bypass rule for authenticated REST API requests.

If you’re not using a CDN or WAF, or you’ve confirmed it’s not the source, move on to the next step.

Step 2: Confirm the 429 Is Coming from Your Server

Before you start pulling apart WordPress, it’s worth confirming that your web server is actually the one returning the 429. Your Apache or LiteSpeed access logs will tell you exactly what’s happening.

grep "wp-json" /home/username/logs/yourdomain.com.access.log | grep " 429 "

For a more detailed view showing timestamps, the requesting IP, and the status code:

awk '$7 ~ /wp-json/ {print $1, $4, $7, $9}' \
  /home/username/logs/yourdomain.com.access.log | tail -50

If you see 429 responses in these logs, WordPress or something running inside it is generating them. If you don’t see them here but your client is still getting 429s, the response is being generated upstream by your CDN, WAF, or a reverse proxy, and you should go back to Step 1.

Step 3: Check for Security Plugins

WordPress security plugins are the most common source of rate limiting that site owners forget about. Wordfence, iThemes Security, Sucuri, All In One WP Security, and Shield Security all have rate-limiting features that can intercept REST API calls.

If you have SSH access, check what’s active:

wp plugin list --status=active --path=/home/username/public_html

If you spot a security plugin, check its settings for rate-limiting or brute-force protection rules that might apply to the REST API. Try temporarily deactivating it to confirm:

wp plugin deactivate wordfence --path=/home/username/public_html

Test your API calls again. If the 429s stop, you’ve found your culprit. Go into the plugin settings and whitelist your IP or adjust the rate-limit thresholds rather than leaving it deactivated.

Step 4: Check the Plugin That’s Exposing the API Endpoint

This is the one people miss. If you’re calling a custom REST API endpoint provided by a specific plugin, that plugin may have its own built-in rate limiter completely independent of any security plugin.

Search for rate-limiting code inside the plugin:

find /home/username/public_html/wp-content/plugins/your-plugin-name/ -iname "*rate*"

grep -ri "rate.limit\|too.many.requests\|429\|throttle" \
  /home/username/public_html/wp-content/plugins/your-plugin-name/ \
  --include="*.php" -l

If you find a file like RateLimiter.php or similar, you’ve found the source. Open it up and see what it’s doing:

cat /home/username/public_html/wp-content/plugins/your-plugin-name/includes/RateLimiter.php

You’ll typically find a class that tracks request counts using WordPress transients or the options table, with a threshold like 10 or 20 requests per minute.

If you’re not sure which plugin is responsible, you can search across all of them at once:

grep -ri "rate.limit\|too.many.requests\|429\|throttle" \
  /home/username/public_html/wp-content/plugins/ \
  --include="*.php" -l

Step 5: Fixing It

Once you’ve identified the source, you have a few options depending on the situation.

Option A: Adjust the Plugin’s Rate Limit Settings

If the plugin has a settings page with rate-limit configuration, increase the threshold to something your automation tool can work within. 20 requests per minute is reasonable for most API integrations. Be aware that 20 requests per second is a very different thing and may cause resource issues on shared hosting.

Option B: Rename or Disable the Rate Limiter File

If the plugin doesn’t have a UI for this and you’re comfortable making changes at the file level, you can rename the rate limiter file as a quick test:

mv /home/username/public_html/wp-content/plugins/your-plugin/includes/RateLimiter.php \
   /home/username/public_html/wp-content/plugins/your-plugin/includes/RateLimiter.php.bak

Important: Only do this if you understand the implications. Rate limiters exist for a reason and they protect your site from abuse. If you disable one, make sure your endpoint is still protected by authentication (Application Passwords, OAuth, etc.) so it isn’t open to the public internet.

Bear in mind that plugin updates will likely overwrite your change, so it’s worth contacting the plugin author and asking for a proper configuration option.

Option C: Throttle Your Automation Tool

Sometimes the simplest fix is on the client side. If your tool is firing requests faster than it needs to, adding a delay between calls can avoid the rate limit entirely:

for endpoint in endpoint1 endpoint2 endpoint3; do
  curl -s -u "user:app_password" \
    "https://yourdomain.com/wp-json/your-plugin/v1/$endpoint"
  sleep 3
done

Step 6: Confirm the Fix

After making changes, watch your access log in real time while you test:

tail -f /home/username/logs/yourdomain.com.access.log | grep "wp-json"

You should see 200 responses instead of 429s.

Nine times out of ten, the 429 is coming from WordPress itself or a plugin, not from the hosting infrastructure. A quick grep through the plugin directory will usually point you straight at the answer.

If you’re a Zume customer and need help diagnosing 429 errors on your account, open a support ticket and we’ll take a look.

Blog

How to Fix HTTP 429 “Too Many Requests” Errors in WordPress: Most Common Solutions