WordPress REST API 401: rest_forbidden_param and rest_not_logged_in With an Application Password

WordPress REST API returns 401 rest_forbidden_param or rest_not_logged_in with an Application Password? What I observed with curl and a short checklist.

If an n8n HTTP Request node (or any HTTP client) calls the WordPress REST API and gets 401 with rest_forbidden_param or rest_not_logged_in, WordPress is treating your request as logged out. On my site it did this even when I sent made-up credentials, so the error does not tell you which part of your credentials is wrong. This guide shows what I observed and a short checklist.

The two errors

Code	English message (from WordPress core)	When I got it
`rest_not_logged_in`	You are not currently logged in.	`GET /wp-json/wp/v2/users/me` without valid credentials
`rest_forbidden_param`	Query parameter not permitted: status	`GET /wp-json/wp/v2/comments?status=hold` without valid credentials

Both come back as HTTP 401. I took the English messages from the WordPress core source (version 7.1.3). My site is set to Korean, so the live responses carried the same codes with Korean text. The code is the part to search for.

What I tested

I sent read-only GET requests with curl to my own site on 2026-10-19. I never sent a request that writes data.

Request	Credentials	Result
`/users/me`	None	401, `rest_not_logged_in`
`/comments?status=hold`	None	401, `rest_forbidden_param`
`/users/me`	Made-up username and made-up password	401, `rest_not_logged_in`
`/comments?status=hold`	Made-up username and made-up password	401, `rest_forbidden_param`
`/posts?per_page=1` (public data)	None	200

Made-up credentials produced exactly the same responses as no credentials. I did not get an "invalid username" or "incorrect password" style error.
Public data (the posts request) worked without credentials, so a 200 there proves only that the site and the REST API are reachable, not that your credentials work.
Asking for pending comments with status=hold is a restricted request. Without a login, WordPress rejects the parameter, which is why this case reports rest_forbidden_param instead of a login message.

A short checklist

Call /wp-json/wp/v2/users/me first with the same credential. In my own workflow this is the first WordPress call. If it returns your user, the credential works. If it returns rest_not_logged_in, fix the credential before debugging anything else.
Use your WordPress username and an Application Password, not your login password. See my guide to n8n and the WordPress REST API with an Application Password.
Make sure the site is served over HTTPS. The WordPress core integration guide says Application Passwords are available by default on sites served over SSL/HTTPS, and that credentials are sent with HTTP Basic Auth.
In n8n, check that the HTTP Request node really uses the Basic Auth credential you created, and that the credential name in the node is the one you edited.
Compare with a public endpoint such as /wp-json/wp/v2/posts?per_page=1. If that works and users/me does not, the problem is authentication, not the network.

What I did not test

I did not test a real username with a wrong password, or a revoked Application Password, so I cannot say whether they look the same.
I did not test a security plugin, proxy or firewall that strips the Authorization header, although that is another way to end up logged out.
I did not test a valid user without enough permissions. WordPress would answer differently in that case.
I used curl, not n8n, so I did not look at how n8n formats this error.
I tested on one site (WordPress 7.1.3).

Source: WordPress core, Application Passwords integration guide. The error codes and English messages are from the WordPress core files on my site.