When the block editor does not save, Site Health misses the REST API, or an integration response is considered invalid, the REST API is broken. There is still insufficient detection. 401 and 403 responses are more related to authentication or policy, 404 to route and rewrite, and 500 to PHP execution. First enter the actual status, URL, method, and body.
Quick answer:Base endpoint/wp-json/Test it, see the JSON response and the header, then repeat the same route with the actual method and identity. Fully disabling WAF, publicising a private endpoint, or disabling TLS verification is not a secure solution.
Turn the signals into a specific request.
- URLs and namespaces, like
wp/v2Or...wc/v3 - method includes GET, POST or PUT
- Status and response body
- An unknown or user accessed the request.
- Time, IP and request ID.
Opening the base endpoint only indicates that the REST dispatcher is available; permission and logic do not guarantee a particular route.
401 and 403: Identity or license
An expired nonce, an incorrect domain cookie, an invalid Application Password, an inadequate capability, or a security rule can reject the request. The difference between your WordPress message and the HTML page generated by a CDN/WAF is important. Do not leave credentials and nonces in the public log. System hours and HTTPS are also checked during signed streams.
404 and rest_no_route
Don't save the permalink from the panel once unless you know the effect of the rewrite change. First check the route is actually registered by the plugin, the method is enabled and the request goes to WordPress.index.phpUnknown copy of the rule may corrupt static or security files.
500 and a non-JSON response.
PHP HTML error, proxy page or warning before JSON can stop the client with invalid JSON. See content type and start of response and timestamp with PHP-FPM andDebug.log and WordPressApply. Follow the stack trace from the first project code.
The phase detection method.
- In the Network window, log the corrupted request.
- Test the base endpoint and the target route separately.
- Don't miscompare an anonymous and authenticated request.
- Follow the CDN, reverse proxy, and origin with the header and request ID.
- Test the security plug-in or cache only in staging and targeting.
- After correcting, read and write and smoke test permissions errors.
wp rewrite list
wp plugin list --status=activeThese commands read information; run the output with the right root of the site and delete sensitive information.
Cache and proxy.
Authenticated or nonce responses should not be cached like public content. Changing the host or scheme in the proxy can ruin the cookie and redirect.Redirect Loop guideSee. Purge without policy adjustment is only temporary.
How do we read the error in the browser?
In DevTools, go to the Network tab, select a failed request, and see the Header, Payload, and Response sections separately. A response textless status is usually not enough. For example, a 403 response with a CDN-related header with a JSON response from WordPress that coderest_forbiddenIt requires two different verification paths. The Preserve log option helps not to delete the pre-redirect request from the list.
If you need to send a request sample to the technical team, first delete the cookie, nonce, authorization, email, and customer data. Copy as cURL is useful, but its output is often credential and should not be included without deletion in a ticket or public message.
Separation of the core, add-on and infrastructure problem
An error on just one specific endpoint is usually closer to the route logger plugin or its permissions./wp-json/Most involve rewrite, proxy, WAF, or PHP execution. If only the writing operation fails but GET works, check the method, nonce, capability, body size limit, and security rules.
On a multilingual or multisite site, also compare the actual URL of the request with the active site and domain. A healthy response from another domain does not necessarily rule out the current domain problem; cookies and network settings may differ for each domain.
What are the limitations of testing with WP-CLI and curl?
curlThe header and TLS are useful for viewing status, but do not reconstruct the entered browser request without a cookie and nonce. WP-CLI also runs WordPress code from the command-line environment and does not necessarily go through CDN and reverse proxy. So WP-CLI's success alongside browser failure can be a sign of HTTP layer failure, not proof of the integrity of the entire path.
curl -i https://example.com/wp-json/
wp rest route listReplace the sample domain with your own domain. Do not install or guess in an environment where the second command is not supported; check the list of WP-CLI commands for the same project. For private endpoint, do not enter credentials directly into the shell history.
What should we test after the correction?
- Loading and storing a test script in the editor
- Public reading request without disclosure of private data
- Writing requests with authorized users and rejection of unauthorized users
- Webhook function or dependent integration
- There was no cached response between the two users.
- Failure to record new errors in PHP and proxy log
Common Mistakes
- Disable the REST API to hide the Site Health alert.
- Send credentials inside the URL or screenshot
- Trust status 200 when the body page is wrong.
- Change the timing of permalink, WAF, and plugins.
- The GET test is broken instead of the POST.
When do you need special assistance?
If the error occurs only behind the CDN, for webhook or when writing data, multi-layer trace is required.WordPress technical troubleshooting serviceIt can track requests from the browser to PHP and route.
Common Questions
Is the REST API a security risk?
The API itself is part of WordPress; routes must have correct callback permission and authentication.
Why is wp-json open but not saved by the editor?
Storage requires a specific route, method, nonce, and capability.
Why does the JSON response start with HTML?
PHP warning, WAF page or login redirect may have come before payload; see header and log of the same request.