WordPress application passwords for the REST API

When to use them

Application passwords let external tools authenticate to the WordPress REST API using the standard Authorization header and a generated password, instead of the user's regular login password. WordPress 5.6 introduced them, and they suit integration clients, scheduled scripts, content importers and third-party apps that need to call API endpoints under a specific user's capabilities.

They matter because sharing a real password is a bad idea: it is reused across systems, cannot be revoked per app, and exposes the account to any tool that stores it. An application password is random, tied to one user, meant to live only in the tool that uses it, and revocable in isolation.

A key limitation is that application passwords work only with cookie-based authentication for end users. For a logged-in browser session the REST API can accept the standard username and password or cookies, while an application password gives a non-interactive client a way to authenticate. They are the intended mechanism for most headless or external WordPress integrations.

Create an application password

1. In the WordPress admin, open Users, then Profile for the account you want to give access to (or your own profile if you are remote-managing a bot).
2. Scroll to the Application Passwords section. If the website runs on HTTPS, the section is enabled by default; if the site is served over plain HTTP it will be disabled, which is a security enforcement you should keep rather than bypass.
3. Enter a name for the app (such as backup-tool or content-import) so you can tell which tool uses it, then Add New Application Password.
4. Copy the generated password once. It is shown only at creation time, so save it into the tool that will use it immediately.

The tool authenticates by sending the key in the Authorization header, typically as base64 of username:application-password:

AUTH=$(printf 'admin:xxxx xxxx' | base64)
curl -H "Authorization: Basic $AUTH" \
  https://example.com/wp-json/wp/v2/posts?per_page=5

Use and revoke it safely

• Scope the user, not the whole site. Create the application password under the user whose capabilities the tool needs rather than the administrator account, so the tool inherits only that user's role. Pair this with the roles and capabilities reference, which explains how the assigned role sets the ceiling on what the token can do.
• One password per tool. Give each integration its own application password. If one tool is compromised or retired, you revoke only that token and the others keep working.
• Keep secrets server-side. Store the token in the tool's environment or configuration, never in a browser, a public script, or source control. A leaked application password is the same as a leaked key.
• Rotate and revoke on completion. When an integration is done, delete the application password from the profile (or via the REST API's application-password endpoints) so the token stops working. Because each token is independent, breaking a stale integration does not disturb live ones.
• Watch for plugin or route conflicts. A plugin that registers its own authentication for a REST route can override or wrap the application-password mechanism; check the endpoints you call return the expected authenticated result after adding a token.

If a tool suddenly returns rest_no_route, rest_cookie_invalid_nonce, or a permission error, confirm the application password was entered without stray spaces, that the user it belongs to still holds the required capability, and that the token has not been revoked. That troubleshooting order isolates whether the issue is the token, the endpoint, or the account's capabilities rather than the whole API.