Debug WordPress REST API 401 and 403 Responses

A 401 usually means usable authentication is absent; a 403 means the server understood the request but refuses it. Plugins and proxies sometimes replace those meanings, so read the JSON error code and response path rather than status alone.

Use the sequence below as a diagnostic method, not as a promise that one setting fits every host; verify its example paths, privileges, and backup assumptions while working to separate authentication, capability, nonce, Authorization-header, security-plugin, and proxy failures in WordPress REST requests.

Likely failure paths

• The request lacks a valid cookie/nonce or Application Password credentials.
• Apache or Nginx does not forward the Authorization header to PHP.
• A security plugin or custom rest_authentication_errors filter blocks the route or anonymous API.

The branches are ordered to protect the strongest evidence around this possibility: the request lacks a valid cookie/nonce or Application Password credentials. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Integration failures happen at custody boundaries; wordPress can format a request successfully while DNS, TLS, a proxy, remote service, authentication layer, or receiving provider rejects the next step; record what each boundary accepted—not just what the WordPress screen announced; in this guide, the practical goal is to separate authentication, capability, nonce, Authorization-header, security-plugin, and proxy failures in WordPress REST requests.

A controlled investigation

1. Request /wp-json/ and the exact route with curl -i; save status, JSON code, and headers.
2. Confirm route method, required capability, user, and authentication mechanism.
3. Check whether Authorization reaches PHP using a safe diagnostic endpoint on staging.
4. Review security/firewall logs before disabling protections.

The sequence moves from observation toward intervention. Preserve the result of the final check—review security/firewall logs before disabling protections—because it provides a useful comparison after the repair.

curl -sS -i https://example.com/wp-json/
curl -sS -i https://example.com/wp-json/wp/v2/types
curl -sS -i -X OPTIONS https://example.com/wp-json/your-namespace/v1/route

Make the smallest durable change

1. Use the authentication method appropriate to the client and HTTPS transport.
2. Forward Authorization using the official Apache/Nginx guidance.
3. Narrow custom restrictions so WordPress admin functions and intended public endpoints still work.

Before applying “Use the authentication method appropriate to the client and HTTPS transport,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can test unauthenticated, authorized, and insufficient-role requests; each should return the intended result; a changed symptom at that point is new evidence, not permission to make several more changes at once.

Close the incident with evidence

• Test unauthenticated, authorized, and insufficient-role requests; each should return the intended result.
• Confirm editor functions that depend on REST still work.
• Remove diagnostic endpoints and secrets.

One successful refresh is not closure. Keep the incident open until you can also confirm editor functions that depend on REST still work, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

A useful escalation contains the UTC timestamp, destination host or route, sanitized request/response headers, status and application error code, correlation ID, retry behavior, and the source IP when relevant; never send live credentials in a ticket; include the result of this first observation: request /wp-json/ and the exact route with curl -i; save status, JSON code, and headers.

State what was tested, including the result of “Request `/wp-json/` and the exact route with `curl -i`; save status, JSON code, and headers,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

Do not trade visibility for a green screen

• WordPress documentation warns that disabling the REST API breaks admin features.
• Do not place Application Passwords in URLs or front-end JavaScript.

Primary references

• WordPress REST API FAQ — official reference consulted for this guide.
• REST API handbook — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Use the authentication method appropriate to the client and HTTPS transport”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.