WordPress REST API Blocked? Fix 403/401 Errors Fast

If Elementor won't load, your contact form silently stops submitting, or the block editor throws "Updating failed" the moment you hit save, there's a good chance the WordPress REST API is the real culprit - not the plugin you're staring at. Here's how to confirm it, find what's blocking it, and fix it without breaking anything else.

What a broken REST API actually looks like

Nobody sees "REST API error" on screen. Instead you get one of these, usually with no obvious link back to wp-json:

• Elementor or Divi stuck on "Loading" forever, or an "ajax request failed" toast
• Gutenberg showing "Updating failed. The response is not a valid JSON response"
• Contact Form 7, WPForms, or Ninja Forms submitting but never sending
• The WordPress mobile app or a headless front-end returning a blank page
• Application Passwords or a REST-based integration (Zapier, a custom app) getting a 401 or 403

All of these lean on /wp-json/ under the hood. When that endpoint returns anything other than clean JSON with a 200 status, the feature built on top of it just quietly fails.

Confirm it before you start changing things

Don't guess - check the endpoint directly first. Open this in a browser or run it from a terminal:

curl -I https://yourdomain.com/wp-json/

A healthy site returns HTTP/1.1 200 OK with a JSON body when you drop the -I flag. If you instead see a 401, 403, 404, or a blank response with an HTML error page mixed into the JSON, you've confirmed the problem is at the API layer and not inside the plugin itself.

Also check the browser console (F12 → Network tab) while reproducing the issue. Look for a request to wp-json/wp/v2/... and note its status code - that tells you exactly which of the causes below applies.

Why the REST API breaks

1. A security plugin is locking it down

Wordfence, iThemes Security, and All In One WP Security all ship an option to disable or restrict the REST API, usually under a name like "Disable REST API" or "REST API Restriction." It's meant to stop anonymous user enumeration through /wp-json/wp/v2/users, but plenty of installs leave it set to "Disable completely," which takes every plugin depending on the API down with it.

Fix: open the security plugin's settings and change the REST API restriction from "Disable entirely" to "Restrict access to authenticated users only," or scope it to just the users endpoint. That keeps the enumeration protection without killing Elementor, Gutenberg, or your forms.

2. .htaccess or an Nginx rule is blocking wp-json

Some hardening guides (including generic ones, not ours) recommend blocking /wp-json/ outright in .htaccess. If someone followed one of those a while back, you'll find a block like this sitting in the file:

# Block WP REST API
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_URI} ^/wp-json/ [NC]
RewriteRule .* - [F,L]
</IfModule>

Fix: remove that block (via cPanel File Manager or SFTP), save, and re-test the curl command. On Nginx, check server or location blocks in your vhost config for anything matching location ~ /wp-json/ that returns 403 or 444.

3. mod_security is flagging the request

On shared and reseller hosting, mod_security rulesets sometimes flag REST API POST requests - especially ones from Elementor's editor or WooCommerce's Store API - as suspicious because of the JSON payload shape. This shows up as a 403 with no explanation in WordPress itself.

Fix: in cPanel, go to Security → ModSecurity and check if it's flagging requests to your domain. You can disable ModSecurity for just that domain, or ask your host to whitelist the specific rule ID from the error log rather than turning it off entirely. Check /home/username/logs/yourdomain.com_error_log or the ModSecurity Audit Log for the rule ID before disabling anything blindly.

4. Permalinks are set to "Plain"

The REST API needs pretty permalinks to route correctly. If permalinks got reset to "Plain" - often after a migration or a database import - /wp-json/ stops resolving and falls back to /?rest_route=/, which most plugins don't know to use.

Fix: go to Settings → Permalinks, pick "Post name," and click Save (even if it already shows "Post name" - resaving regenerates the rewrite rules). If it still 404s afterward, flush rewrite rules again from WP-CLI:

wp rewrite flush --hard

5. A caching or CDN layer is caching the 403 itself

If you fixed the actual cause above but still see the same error, check whether Cloudflare, a page cache plugin, or a server-level cache is serving a cached copy of the failed response. REST API calls should never be cached - confirm your cache exclusion rules cover /wp-json/* and purge cache after making any of the fixes above.

Quick reference: symptom to cause

Prevention

• Whenever you enable a security plugin's REST API restriction, test Elementor/Divi, your contact form, and the block editor immediately afterward - don't assume it's fine.
• Keep a copy of your working .htaccess before applying any hardening snippet you found online, including from your own host's docs.
• Exclude /wp-json/* from page caching and CDN caching by default - it should never be treated as static content.
• After any migration, check permalinks and the REST API status before declaring the migration done.