Throttled WordPress REST API requests are requests slowed or blocked after exceeding a rate limit. To diagnose them, check the status code, test the REST API directly, review Site Health, then match timestamps and request IDs in firewall and hosting logs. The REST API is the JSON interface themes, plugins, and outside apps use to read and update site data. Self-hosted WordPress sets no single universal quota, so throttling usually comes from the host server, CDN, web-application firewall, or security plugin rather than WordPress core itself, according to Hostinger's guide to 429 errors.
Table of Contents
- Where rate limits actually live
- What a throttled response looks like
- How to confirm the source
- Reduce requests without breaking WordPress
Where rate limits actually live
Limiting happens at the layer that sees too many requests first. That is often a hosting per-visitor rule, CDN protection, firewall, or a plugin that limits logins, spam, or API calls. WordPress core does not impose one shared number for all sites.
The signal varies by layer. Throttled API requests often return HTTP 429 Too Many Requests, while LiteSpeed or hosting per-visitor limits may express the same pressure as 503. Security and API-limiter plugins return 429 by design.
What a throttled response looks like
A rate-limited REST response should include a Retry-After header with the 429 response. Clients should honor that pause with delayed retries and exponential backoff instead of repolling at once.
Immediate repolling keeps the client over the limit. A direct check helps separate throttling from blocking. According to WP Fix It's REST API guide, a visit to https://example.com/wp-json/ should return JSON route data, so a login page, 403, 406, redirect loop, timeout, or other error points toward auth, firewall, SSL, plugin, or hosting causes.
How to confirm the source
Start under Tools, then Site Health, then Status. Expand the REST API and loopback test and record the message, tested URL, and whether the result is rated as recommended or critical.
That record anchors the rest of the check. Capture the failing request in browser DevTools under Network response headers: Match that timestamp and /wp-json/ path in firewall, proxy, and origin-host blocked-request logs. The same URL appearing at the same time across layers shows which service refused it.
- failing /wp-json/ URL and query string
- timestamp and status code
- x-hcdn-request-id where present
- Retry-After value on 429 responses
Reduce requests without breaking WordPress
Polling frequency is a common cause and a practical fix. Headwall WP Tutorials calculates that one 1MB REST response every 5 seconds equals about 17GB per day, so affected owners and API clients should cache responses, slow polling, paginate large sets, and use short per-IP request windows such as 10 seconds.
Do not disable the REST API to avoid limits. The WordPress Developer Handbook FAQ warns that disabling it breaks admin and block-editor functions, and instead advises requiring authentication through the rest_authentication_errors filter or narrowly allowing the legitimate /wp-json/ request.
You Might Also Like
- WordPress Maintenance: Staging Tests After Cloud Account Recovery: Which Integrations Should Be Checked Before Production?
- WordPress Maintenance: Recovery Admin Accounts: How to Test Access Without Disabling the Main Login
- WordPress Maintenance: Membership Sites Using Google Login: How to Review Legitimate Account-Linking Options
