What the REST API is and why it matters for site owners #
The WordPress REST API is how WordPress communicates with itself and with external services using a standard web protocol. When you interact with modern WordPress functionality, the REST API is often running silently in the background. The Block Editor saves your post via a REST API request. WooCommerce cart updates happen via REST API. Contact Form submissions in some plugins go through the REST API. Authentication handshakes use it. If the REST API is broken or blocked, features that depend on it stop working, usually without a clear error message that points to the API as the cause.
Most non-technical site owners don’t know the REST API exists. They just know that the Checkout Button stopped working, or the Block Editor shows “Updating failed,” or a form that used to submit silently breaks. The REST API is frequently the invisible layer in the middle of those failures.
What Loupely captures from REST API activity #
The Loupely WordPress Plugin records REST API requests and responses that occur during the diagnostic capture window. This includes:
- the endpoint that was called
- the HTTP status code returned (200, 400, 401, 403, 404, 500, and so on)
- the response body, including error messages that never reach the browser in readable form
- any PHP Errors that fired on the server while handling the request
That last item is the most valuable one. A REST API request that returns a 500 status almost always means a PHP error fired on the server while processing the request. The browser sees a 500 and produces a JavaScript error. Most debugging approaches stop at the JavaScript error. Loupely correlates the JavaScript error with the PHP error that caused the 500, which is where the actual diagnosis lives.
What REST API status codes mean for your site #
200 (Success): The request completed and returned the expected data. If you’re getting 200 responses but things still aren’t working, the response body may contain malformed data or an error message formatted as a success response. Some plugins return 200 with an error payload, which is why Loupely captures the response body, not just the status code.
400 (Bad Request): The request was malformed. Often caused by a plugin sending incorrect data to an endpoint, or by a mismatch between what the client expects to send and what the endpoint expects to receive.
401 (Unauthorized): The request requires authentication that wasn’t provided or wasn’t accepted. In WordPress, this frequently means a nonce has expired (nonces are security tokens that WordPress generates and validates per request), or a caching plugin is serving a stale page with an old nonce to a user who needs a fresh one.
403 (Forbidden): The server understood the request but refused to process it. Unlike 401, re-authenticating won’t help. In WordPress, 403s often come from security plugins blocking REST API requests, incorrect file permissions, or ModSecurity rules on the server treating a legitimate WordPress request as suspicious.
404 (Not Found): The endpoint doesn’t exist at the URL that was requested. This can happen after permalink changes, after plugin updates that change endpoint paths, or when a plugin that registered a custom endpoint is deactivated.
500 (Internal Server Error): Something broke on the server while handling the request. Almost always a PHP error. Loupely’s cross-signal correlation links this status code to the specific PHP error in the server capture.
When the REST API itself is disabled or blocked #
Some security plugins and some hosting configurations restrict REST API access. WordPress’s own Site Health tool will flag this as a critical issue if the REST API is fully disabled, because it breaks the Block Editor and other core functionality. If Loupely diagnoses a REST API blockage as the cause of a failure, the triage step will identify whether the block is coming from a security plugin (and which one), from your server configuration, or from your hosting provider’s firewall.