What matters first: The REST route exists, but WordPress or an authentication layer did not accept the supplied credentials. Browser cookies, REST nonces, application passwords and bearer tokens fail for different reasons.
What this symptom actually tells you
A 401 is useful because it narrows the incident to identity and authorization. The response code, WWW-Authenticate header and user context show whether the request never authenticated or authenticated without the required capability.
Capture evidence before changing anything
- Call the same endpoint without credentials and with the intended credential method.
- Record the response body and WWW-Authenticate header.
- Confirm the user account is active and has the capability required by the route.
- Check whether a proxy or security rule strips Authorization headers.
Most common causes
- Missing REST nonce: Cookie-authenticated browser requests need a current wp_rest nonce.
- Stripped Authorization header: Apache, Nginx, a proxy or CDN may not pass Basic or Bearer credentials to PHP.
- Revoked application password: The password may have been deleted, rotated or tied to a different user.
- Capability mismatch: Authentication succeeds but the endpoint’s permission callback denies the user.
Safe diagnostic and repair sequence
- Choose one authentication method and test it outside the application with a minimal request.
- Pass the Authorization header through every proxy and web-server layer.
- Generate a new application password only for the required user and integration.
- Verify the endpoint’s permission callback against the intended role rather than granting broad administrator access.
How to choose between the likely causes
Do not treat Missing REST nonce and Stripped Authorization header as interchangeable. Cookie-authenticated browser requests need a current wp_rest nonce. By contrast, apache, Nginx, a proxy or CDN may not pass Basic or Bearer credentials to PHP. Use two checks to separate them: Call the same endpoint without credentials and with the intended credential method; and record the response body and WWW-Authenticate header. Those observations usually show whether the next safe move is to choose one authentication method and test it outside the application with a minimal request or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Never expose a WordPress password in URLs, logs or JavaScript. Use application passwords or a purpose-built token and rotate it after testing.
How to verify the repair
- The integration authenticates with the intended non-interactive credential.
- The same user can access only the routes and methods it needs.
- Authorization headers and secrets do not appear in public logs or page source.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
A 401 is useful because it narrows the incident to identity and authorization. The response code, WWW-Authenticate header and user context show whether the request never authenticated or authenticated without the required capability.
Call the same endpoint without credentials and with the intended credential method.
Record the response body and WWW-Authenticate header.
Confirm the user account is active and has the capability required by the route.
Check whether a proxy or security rule strips Authorization headers.
What must be verified
- The integration authenticates with the intended non-interactive credential.
- The same user can access only the routes and methods it needs.
- Authorization headers and secrets do not appear in public logs or page source.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Does a 401 mean the REST endpoint itself is broken or missing?+
No. A 401 confirms the route exists and was reached; it only means the supplied credentials were not accepted. That is a narrower and easier problem than a missing or misconfigured route, which would typically return a 404 instead.
My application password worked before — why did it suddenly start returning 401?+
Application passwords stop working if they are deleted, rotated, or associated with a different user than the one making the request. Generate a fresh application password for the exact user and integration involved and confirm it is entered without extra whitespace.
I'm sending valid Basic auth credentials but still get 401 — what should I check next?+
Apache, Nginx, a proxy, or a CDN can strip the Authorization header before it reaches PHP, even when the credentials themselves are correct. Test the header at each layer between the client and PHP to confirm it survives the full path.
Is it ever okay to put a WordPress password directly in a request URL to get past this?+
No, never expose a password in a URL, log, or client-side JavaScript. Use an application password or a dedicated token instead, and rotate it after testing to limit exposure.