If your site sits behind Cloudflare and a rate limiting rule is active, that rule can also match the WP STAGING REST API. Cloudflare then answers those requests with HTTP 429 (Too Many Requests) and WP STAGING features that depend on the REST API stop working. The fix is a one line exclusion in the rate limiting rule.
Why does Cloudflare rate limiting break the WP STAGING REST API?
Cloudflare rate limiting rules match on the incoming request, not on the plugin that sent it. A rule written for your whole domain, or for a busy path such as /booking, also counts the internal requests WP STAGING makes to its own REST API.
Once the counter is exceeded, Cloudflare blocks further matching requests and returns HTTP 429. WP STAGING never reaches WordPress, so the calling feature fails or hangs.
Your site is affected if all of the following are true:
- Cloudflare Rate Limiting is enabled on the zone.
- A rate limiting rule matches the WordPress site or a path within it, for example
/booking. - That rule does not exclude the WP STAGING REST API.
Which WP STAGING features stop working?
The WP STAGING REST API is used by several features, including:
- Background jobs
- Remote Sync
- Magic Login
- Plugins Auto Update
- Other REST API based functionality
When these requests are rate limited they fail with HTTP 429, and the feature that triggered them cannot complete.
How do I exclude the WP STAGING REST API from Cloudflare rate limiting?
Edit the rate limiting rule so it no longer matches WP STAGING REST API requests.
Step 1: Open your rate limiting rules
In the Cloudflare dashboard, select your account, then your domain, then go to Security and open Security rules. Your rate limiting rules are listed there.
Step 2: Edit the rule that matches your WordPress site
Open the rule that covers the WordPress site or the path where the 429 responses appear.
Step 3: Add the exclusion to the rule expression
Append this condition to the rule’s matching expression:
and not http.request.uri.query contains "/wpstg/v1"A complete expression for a rule that protects /booking then looks like this:
(http.host eq "example.com" and starts_with(http.request.uri.path, "/booking")) and not http.request.uri.query contains "/wpstg/v1"Step 4: Deploy the rule
Save and deploy. Requests such as the one below are no longer rate limited, while the rest of your site stays protected:
?rest_route=/wpstg/v1/check_magic_loginNote:
wpstg/v1is part of the query string, not the URL path. WP STAGING calls its REST API through the?rest_route=form, so usehttp.request.uri.queryrather thanhttp.request.uri.pathin the exclusion.
FAQ
Why does the exclusion use http.request.uri.query and not http.request.uri.path?
WP STAGING builds its REST URLs as https://example.com/?rest_route=/wpstg/v1/<endpoint>. The wpstg/v1 namespace therefore appears in the query string. A rule matching on http.request.uri.path would never see it, and the exclusion would silently do nothing.
Does this exclusion weaken my site’s protection?
It exempts only requests whose query string contains /wpstg/v1. Every other request to your domain still counts toward the rate limiting rule.
I also see 429 errors on /wp-json/wpstg/v1/. What then?
Some setups reach the REST API through the pretty permalink form instead. In that case add a second condition for the path as well:
and not starts_with(http.request.uri.path, "/wp-json/wpstg/v1/")Could something other than Cloudflare cause the 429?
Yes. Web application firewalls, host level rate limiting, and security plugins can all return HTTP 429. Check your server and plugin logs if the errors continue after deploying the Cloudflare exclusion.
How do I confirm the fix worked?
Trigger the failing feature again, for example open a Magic Login link or start a Remote Sync, and check the Cloudflare Security Events log. Requests containing /wpstg/v1 should no longer show a rate limiting block action.
