The REST API Encountered an Error: WordPress Fix

Site Health has flagged a critical issue titled “The REST API encountered an error”. Expand it and WordPress explains that the REST API is one way WordPress and other applications communicate with the server, then lists the address it tried and what came back, something like “REST API Response: (403) Forbidden” or “Error: cURL error 28: Operation timed out”. A close cousin reads “The REST API encountered an unexpected result”.

You may have come here from Site Health with nothing else wrong. More often there is a second symptom: posts will not save, the block editor shows errors, a form plugin has stopped submitting, or a page builder hangs. The REST API sits underneath all of those, so when it is blocked they fail together. This post explains what the test actually does, how to read the response code it shows you, and how to find what is blocking it.

What the REST API is, in one paragraph

The REST API is a set of addresses under /wp-json/ on your own site that return data instead of web pages. The block editor uses it to load and save posts. Many plugins use it for forms, search, carts and settings screens. Mobile apps and outside services use it to read or write content. When WordPress tests it in Site Health, it sends a request from your server to one of these addresses on your own site, for example /wp-json/wp/v2/types/post, and checks that a sensible answer comes back.

Reading the response Site Health shows you

The code in brackets is the most useful clue on the screen. Note it down before you change anything.

(401) Unauthorized

The request reached WordPress, but WordPress did not accept it as coming from a logged-in user. This often points to a plugin or server rule stripping the cookies or authentication headers from the request, or to the site being behind a password prompt such as HTTP basic authentication on a staging copy.

(403) Forbidden

Something refused the request outright. The most common culprits are a security plugin set to disable or restrict the REST API, a web application firewall rule at the host, or a CDN challenge page. If the response body mentions a security product by name, that is your answer.

(404) Not Found

The /wp-json/ addresses are not being routed to WordPress. This is usually a rewrite problem: a missing or damaged .htaccess file on Apache, or a server configuration that does not pass these addresses to WordPress on Nginx. It often comes with pages other than the home page also returning 404, which we cover in the post on every page except the home page showing 404.

(500) Internal Server Error

WordPress or a plugin crashed while handling the request. The PHP error log will normally say exactly where.

A cURL error instead of a code

The test never got an answer at all. Your server could not reach itself, either because a firewall blocked the loopback, the site took too long to respond, or a certificate problem stopped the secure connection. We explain those codes in our post on cURL errors in WordPress.

“Unexpected result” with a 200 code

The request succeeded but the answer was not valid data. Usually a plugin or theme is printing something, a PHP warning, an empty line or a bit of HTML, before or after the real response. That same stray output is a common reason the block editor refuses to save and complains about JSON.

A quick test you can do in your browser

Open a private window and visit https://yourdomain.com/wp-json/. You should see a long block of text starting with your site’s name and description in a structured format. Some browsers display it neatly; others show raw text. Either is fine.

• If you see that text, the REST API is reachable from the outside, and the problem is more likely the server’s ability to reach itself, or something specific to logged-in requests.
• If you see a 404 page, rewrites are the problem.
• If you see a security plugin’s block message or a firewall page, you have found the culprit.
• If you see a blank page or an error, check the logs.

If your permalinks are set to “Plain”, WordPress uses /?rest_route=/ instead of /wp-json/, so try that address too.

Causes, most likely first

1. A security plugin restricting the API. Many security and hardening plugins have an option to disable the REST API for visitors who are not logged in, or entirely. Disabling it entirely breaks the editor and many plugins. Restricting it for anonymous visitors is usually fine, as long as the plugin does it carefully. Our article on choosing a WordPress security plugin talks about the trade-offs.
2. A firewall at the host or CDN. Server-side firewalls such as ModSecurity, or rules on a CDN, can block requests to /wp-json/ that look unusual. Logged-in admin requests that send a lot of data are especially likely to trip them.
3. Rewrite rules. A missing .htaccess or a server move that did not carry the rewrite configuration across.
4. A plugin conflict. One plugin registering a broken route, or altering every API response, can upset the whole API.
5. PHP errors being displayed. With error display switched on, a harmless warning gets printed into the middle of the API’s answer and spoils it.
6. Loopback blocked. The host does not let the server request its own domain, or the domain resolves to the wrong address from inside the server.
7. Password protection on a staging site. If the whole site sits behind a server password prompt, Site Health’s request is turned away. On a staging copy this warning can be ignored.

Fixing it step by step

1. Take a backup. You may end up deactivating plugins or editing .htaccess, and both are easier to undo with a fresh copy to hand.
2. Resave permalinks. Go to Settings → Permalinks and click Save Changes without changing anything. WordPress rewrites its rules. It is harmless and it fixes a surprising number of 404 responses.
3. Check your security plugin’s REST API settings. Look for options named along the lines of “disable REST API” or “restrict REST API”. Switch off any full disable and re-run Site Health.
4. Check firewall and CDN logs. If you use a CDN, look at its event or firewall log for blocked requests to /wp-json/ around the time you ran the test. Your host can do the same for its server firewall, and can add an exception for a specific rule if one is to blame.
5. Turn off on-screen PHP errors. Make sure errors go to a log file rather than the page. Our guide on using WordPress debug mode safely shows the settings.
6. Look for a plugin conflict. On a staging copy, or at a quiet time on the live site, deactivate plugins in groups and re-run Site Health after each group. When the error clears, reactivate the last group one by one. Leave the security plugin and anything that handles payments until last on a live site.
7. Switch to a default theme briefly if plugins are ruled out. Themes can register API routes too.
8. Ask the host about loopback if the error is a cURL timeout and everything above is clean.

Should you just disable the REST API?

Some older security advice recommends switching it off completely to hide information. On a modern WordPress site that breaks the block editor, many contact forms, WooCommerce features and most page builders. A more sensible position is to leave it on for logged-in users and plugins that need it, and limit what anonymous visitors can see, for example the list of user accounts. A good security plugin can do that without breaking the rest of the site.

Which Site Health warnings to worry about

This one is worth fixing on a live site, because it usually means real features are failing quietly. Some other warnings on the same screen are only advice. Our tour of the Site Health screen and which items matter separates the two, and the main WordPress errors and fixes guide links to the rest of the error family.

Does this affect your visitors?

Sometimes not at all. A blog with no forms and a classic theme can run for a long time with this warning and nobody outside notices. The trouble is that you cannot tell from the warning alone. A contact form that submits through the API, a product filter, a cart that updates without reloading the page, or a booking widget can all be failing for visitors while the pages themselves load normally. After you fix the error, test those features yourself as a visitor would, in a private window, rather than assuming they were fine all along.

Keeping the API working

• After installing a security plugin or turning on a new firewall rule, open the block editor and save a draft. If that works, the API is fine.
• Keep error display off on the live site at all times.
• After a hosting move, resave permalinks and check Site Health the same day.
• Avoid running two security plugins that both try to control the API.

If you are stuck

REST API errors are often caused by one plugin fighting another or a firewall rule nobody remembers adding, which takes patient testing to pin down. If you would rather not do that on a live site, send us the Site Health text and the response code. We will work on a staging copy where we can, find what is blocking the request, and explain what we changed. Our help for plugins that clash with each other is usually the right fit.

Next in this series: Updating Failed: Not a Valid JSON Response in WordPress