WordPress Errors

WordPress REST API Error

Advanced Risk: medium

Last reviewed August 7, 2026

Hosting access may not be needed Database access usually not needed

Direct answer

A WordPress REST API error means requests to `/wp-json/` are failing or returning malformed responses, which breaks the block editor, page builders, and any app talking to your site over the API. Confirm `/wp-json/` returns valid JSON directly in the browser, check for permalink or `.htaccess` problems, then rule out plugin/security-plugin blocks before assuming the REST API itself is broken.

The REST API is what the block editor, many page builders, mobile apps, and headless front ends use to read and write content behind the scenes — when it fails, the symptom is usually “editor won’t load” or “changes won’t save” rather than an obvious API error message. This guide shows how to confirm the REST API is the actual fault, separate permalink/server issues from plugin and security blocks, and restore it without disabling features you still need.

Advanced

Key facts

Verifiable numbers and definitions — each claim links to its source.

The WordPress REST API exchanges site data as JSON and is the foundation of the block editor and many modern plugin UIs. (REST API Handbook)
With pretty permalinks enabled, WordPress advertises the API root at /wp-json/ via a Link header with rel=https://api.w.org/. (REST API Discovery)
Without pretty permalinks, discovery falls back to the ?rest_route=/ query form instead of /wp-json/. (REST API Discovery)
Core content endpoints live under the wp/v2 namespace; clients should confirm that namespace before calling those routes. (REST API Discovery)

What the error means

The WordPress REST API exposes your site’s posts, pages, media, users, and settings as JSON over HTTP at routes like `/wp-json/wp/v2/posts`, and it is the foundation the block editor and many modern themes/plugins are built on. A “REST API error” can mean the endpoint returns a PHP fatal instead of JSON, returns HTML (a theme template, a firewall block page, or a login redirect) where JSON was expected, returns a 403/401 that blocks legitimate requests, or fails to route at all because permalinks are broken. Each of those looks like “the editor is broken” to a site owner but has a different root cause and fix.

Common symptoms

Block editor (Gutenberg) shows “Updating failed” or spins forever when saving
Visiting `/wp-json/` directly in the browser shows a 404, a PHP error, or a blank page instead of JSON
Page builder (Elementor, Divi, Beaver Builder) fails to load or save with a console error mentioning REST or `wp-json`
Browser console shows a failed fetch/XHR to a `/wp-json/` URL with a non-200 status or invalid JSON response
A previously working mobile app, headless front end, or integration suddenly cannot read or write content
REST requests succeed when logged out but fail when logged in (or the reverse), suggesting an auth/nonce issue
Site Health in wp-admin flags a REST API check failure

Most likely causes

01 Permalinks set to “Plain” or a corrupted `.htaccess`/rewrite configuration preventing `/wp-json/` routes from resolving
02 Security plugin, host firewall, or Cloudflare WAF rule blocking requests to `/wp-json/` or specific REST routes
03 A plugin or theme fataling during REST request handling, so the response is a PHP error instead of JSON
04 Something (a plugin, a stray space, or a BOM character in a file) printing output before headers, corrupting the JSON response
05 REST API disabled or restricted entirely by a security/performance plugin “hardening” setting
06 Authentication/nonce mismatch caused by aggressive caching serving a stale nonce to logged-in users
07 Custom endpoint or plugin registering a route that conflicts with or overrides a core REST route

What changed before the problem started

Security plugin installed or its REST API restriction setting enabled
Permalink structure changed, or `.htaccess` was edited or regenerated
New firewall, Cloudflare rule, or hosting-level WAF policy added
Plugin or theme update introduced a fatal in code that hooks into REST requests
Caching plugin or CDN configuration changed around how logged-in/AJAX/REST traffic is handled

Troubleshooting steps

Troubleshooting flow

Permalinks set to “Plain” or a corrupted `.htaccess`/rewrite configuration preventing `/wp-json/` routes from resolving

Security plugin, host firewall, or Cloudflare WAF rule blocking requests to `/wp-json/` or specific REST routes

A plugin or theme fataling during REST request handling, so the response is a PHP error instead of JSON

Something (a plugin, a stray space, or a BOM character in a file) printing output before headers, corrupting the JSON response

01
Test the REST API root directly in the browser
Visit yoursite.com/wp-json/ in a private browser window. You should see JSON describing your site’s routes. A 404 points at permalinks/rewrite rules; a PHP error or blank page points at a fatal; HTML from your theme or a firewall points at routing or a security block — this single test narrows the whole investigation.
02
Resave permalinks
Go to Settings → Permalinks, choose a structure other than “Plain” if that is currently selected, and click Save (even without changing anything). This regenerates rewrite rules and `.htaccess` entries that REST routes depend on, and fixes a large share of “REST API returns 404” cases immediately.
03
Check the browser console and Network tab while reproducing the failure
Open DevTools, reload the editor or builder, and watch for the failing `/wp-json/` request. Note its status code (403, 404, 500) and response body — a security plugin block usually returns a readable message; a fatal returns PHP error text; a routing failure returns WordPress’s standard 404 JSON.
04
Temporarily disable security/firewall REST restrictions
Many security plugins have an explicit “Disable REST API” or “Restrict REST API to logged-in users” toggle. Turn it off, clear any related cache, and retest. If the editor recovers, you know the block was intentional hardening rather than a bug, and you can re-enable it with an explicit allowlist instead of a blanket block.
05
Purge caching and CDN layers, especially for logged-in traffic
Clear WordPress page cache, object cache, and any CDN/Cloudflare cache. Confirm wp-admin and REST requests for logged-in users are excluded from full-page caching — a stale cached nonce is a common cause of “save failed” errors that look like REST API problems.
06
Read PHP error logs for the request timestamp
If `/wp-json/` itself shows a PHP error or blank page, check your host’s PHP error log for a fatal at that time. The file path named there is almost always the plugin or theme code actually breaking the REST response, not the REST API framework itself.

Test the REST API root directly in the browser

Visit yoursite.com/wp-json/ in a private browser window. You should see JSON describing your site’s routes. A 404 points at permalinks/rewrite rules; a PHP error or blank page points at a fatal; HTML from your theme or a firewall points at routing or a security block — this single test narrows the whole investigation.

Resave permalinks

Go to Settings → Permalinks, choose a structure other than “Plain” if that is currently selected, and click Save (even without changing anything). This regenerates rewrite rules and `.htaccess` entries that REST routes depend on, and fixes a large share of “REST API returns 404” cases immediately.

Check the browser console and Network tab while reproducing the failure

Open DevTools, reload the editor or builder, and watch for the failing `/wp-json/` request. Note its status code (403, 404, 500) and response body — a security plugin block usually returns a readable message; a fatal returns PHP error text; a routing failure returns WordPress’s standard 404 JSON.

Temporarily disable security/firewall REST restrictions

Many security plugins have an explicit “Disable REST API” or “Restrict REST API to logged-in users” toggle. Turn it off, clear any related cache, and retest. If the editor recovers, you know the block was intentional hardening rather than a bug, and you can re-enable it with an explicit allowlist instead of a blanket block.

Purge caching and CDN layers, especially for logged-in traffic

Clear WordPress page cache, object cache, and any CDN/Cloudflare cache. Confirm wp-admin and REST requests for logged-in users are excluded from full-page caching — a stale cached nonce is a common cause of “save failed” errors that look like REST API problems.

Read PHP error logs for the request timestamp

If `/wp-json/` itself shows a PHP error or blank page, check your host’s PHP error log for a fatal at that time. The file path named there is almost always the plugin or theme code actually breaking the REST response, not the REST API framework itself.

When to stop troubleshooting

Stop DIY changes if you cannot access server-level configuration (nginx, WAF, reverse proxy) needed to confirm routing, the REST API failure is blocking a live store or membership site from accepting orders or logins, multiple plugins interleave in the failure and you lack staging, or you suspect a security plugin is intentionally blocking traffic you cannot safely re-enable without exposing the site. Escalate with the exact `/wp-json/` response, status code, and recent plugin/security changes.

Information to collect before requesting help

01 Exact symptom: editor save failure, builder not loading, integration broken, or Site Health warning
02 Raw response body and status code from visiting `/wp-json/` directly
03 Browser console/Network tab capture of the failing REST request
04 Whether the failure happens logged out, logged in, or both
05 Security plugin(s) installed and whether any REST API restriction setting is enabled
06 Recent permalink, `.htaccess`, plugin, theme, or hosting/firewall changes
07 PHP error log excerpt if `/wp-json/` itself errors
08 Whether a CDN, Cloudflare, or reverse proxy sits in front of the site

How a professional repairs the problem

A pro confirms exactly how the REST API is failing by inspecting the raw `/wp-json/` response, then separates routing (permalinks, rewrite rules, proxy config) from application faults (plugin fatals, stray output) and access blocks (security plugin or firewall rules). We resave permalinks and fix `.htaccess` where needed, isolate the offending plugin via safe conflict-testing, correct or replace custom REST route code, and re-enable any intentional security restrictions with a proper allowlist instead of a blanket block — then verify the editor, builders, and any integrations save and load cleanly.

Frequently asked questions

Is the REST API the same thing as `admin-ajax.php`? +

No. Both let JavaScript talk to WordPress, but `admin-ajax.php` is the older action-based system while the REST API exposes structured JSON routes under `/wp-json/`. The modern block editor and most current page builders rely primarily on the REST API.

Can I just disable the REST API to fix a security warning? +

Not without breaking core features. The block editor and many plugins require it to function. If a security scanner flagged the REST API, restrict specific sensitive routes (like the users endpoint) instead of disabling the entire API.

Why does `/wp-json/` work for me but not for other users? +

That pattern usually points to a caching layer serving a stale authentication nonce to logged-in visitors, or a security rule that treats logged-in and logged-out requests differently. Check cache exclusions for wp-admin and REST paths first.

Will resaving permalinks break my existing URLs? +

No, as long as you keep the same structure you already use. Resaving without changing the structure simply regenerates rewrite rules and commonly fixes REST 404s without affecting your published URLs.

A plugin update broke the REST API — what now? +

Roll back to the previous plugin version from backup or the vendor’s release archive while you confirm the fatal in the PHP log, then update again once a compatible release is available or the conflicting code is fixed.

Does a REST API error mean my site was hacked? +

Rarely on its own. Most REST API errors trace to permalinks, a plugin conflict, or a security plugin’s own restriction setting. Treat it as a hacking concern only alongside other signs like unfamiliar admin users or unexpected file changes.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

You will receive a clear explanation of the likely cause.
We will tell you if the issue falls outside our repair scope.
No additional work will be performed without approval.
A backup should be created whenever access and website condition allow it.

Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.