If you run a content site that integrates with external services—publishing tools, mobile apps, automation chains—you’re probably hitting the WordPress REST API dozens or hundreds of times a day. And at some point, you’ll see a 429 response or a cryptic timeout, even though WordPress core itself ships with no built-in rate limit on REST endpoints.
The throttle isn’t coming from WordPress. It’s coming from the layers wrapped around it: your hosting environment, Web Application Firewall, caching plugin, or a security tool you installed six months ago and forgot about.
Here’s where REST API rate limits actually live, how to identify which one is blocking you, and when raising the cap makes sense.
WordPress core has no REST API rate limit
WordPress itself does not enforce a request-per-minute cap on /wp-json/ endpoints. The REST API documentation (checked October 2026) confirms this: authentication and capability checks exist, but no native throttle.
If you’re seeing rate-limit responses, they’re being injected upstream or by a plugin. The most common culprits:
- Web Application Firewall (WAF) rules at Cloudflare, Sucuri, or your host’s edge
- Hosting-level throttles applied to
admin-ajax.phpand/wp-json/paths - Security plugins like Wordfence, iThemes Security, or All In One WP Security
- Caching plugins with REST API exclusion rules that block rather than cache
Each throttles differently, logs differently, and requires a different fix.
Hosting-level limits: check your control panel first
Managed WordPress hosts—especially those optimised for high traffic—often apply rate limits to resource-heavy endpoints. These caps protect shared infrastructure but aren’t always documented in your plan details.
At BigScoots and similar managed hosts, REST API requests may be capped at 60–120 requests per minute per IP address. If you’re running a headless frontend, mobile app, or Zapier automation that polls frequently, you’ll hit this quickly.
Check your hosting dashboard for firewall or security settings. Some hosts surface REST API rules under “Advanced” or “Performance” tabs. If you don’t see anything, open a support ticket—most will raise the limit or whitelist your integration’s IP within a few hours.
Security plugins: look for REST API settings buried in advanced tabs
Wordfence, iThemes Security, and similar plugins can block or throttle REST requests as part of brute-force protection. The setting is rarely front-and-centre.
In Wordfence, navigate to Firewall → All Firewall Options → Rate Limiting. You’ll see separate rules for login attempts, 404s, and—sometimes—REST API calls. The default may be as low as 10 requests per minute from a single IP.
If your automation or app uses a fixed IP, whitelist it under Tools → Whitelisted IPs rather than disabling the throttle entirely. If the IP rotates (common with cloud functions or SaaS tools), you’ll need to raise the per-minute cap or exempt the specific endpoint your integration calls.
iThemes Security groups REST API controls under Settings → Advanced → REST API. You can disable access entirely, restrict to authenticated users, or allow open access. There’s no granular per-endpoint throttle in the free version.
When to raise limits vs. refactor your integration
Raising a rate limit is the right move when you control the integration and know the request volume is legitimate—publishing workflows, syncing subscriber counts, or feeding a mobile app.
But if you’re polling every few seconds because you don’t have webhook support, the real fix is architectural. WordPress supports action hooks that fire when content changes. Use those to push updates to your external service instead of pulling on a loop.
For example, if you’re auto-posting new articles to social media, hook into publish_post and send the data once. That replaces a 60-requests-per-hour polling schedule with a single request per publish event.
Similarly, if you’re syncing email subscriber counts, check whether your ESP offers a webhook that pings your WordPress install when the count changes, rather than polling their API every five minutes.
How to test which layer is blocking you
If you’re not sure where the throttle lives, make a series of rapid REST API calls and watch the response headers.
Use curl or Postman to hit https://yoursite.com/wp-json/wp/v2/posts twenty times in quick succession. Look for:
- HTTP 429 with a
Retry-Afterheader—likely a WAF or hosting firewall - HTTP 403 with a Wordfence or security-plugin signature in the body—plugin block
- Timeout or connection reset—server-level resource limit, not a REST-specific rule
Check your server error logs (usually under /logs/ in your hosting panel or via SSH at /var/log/apache2/error.log or /var/log/nginx/error.log). Rate-limit blocks often leave a timestamped entry naming the rule or plugin that triggered them.
If nothing appears in logs and responses are clean until request 61, your host is applying an undocumented per-minute cap. Contact support with the exact timestamp and endpoint—they’ll confirm and adjust if appropriate.
Running a content site with integrations that depend on the REST API? Subscribe to One Two Three Send for weekly breakdowns of the infrastructure details that trip up solo operators—delivered every Wednesday.
One non-obvious tip: exempt RSS-to-email tools from REST throttles
If you use Zapier, Make, or an RSS-to-email service to auto-send new posts to your list, those tools often poll your site’s RSS feed—which some setups route through the REST API via /wp-json/wp/v2/posts?_embed.
Throttling that endpoint can delay your email send by hours. Whitelist the tool’s IP range or exempt the specific /wp/v2/posts path from rate rules. Most security plugins let you exclude endpoints by regex pattern.
For Zapier, the current IP ranges are published in their help docs (checked October 2026). Add those to your firewall’s allowlist if you’re seeing delayed triggers.