Authentication

Pro

The REST API uses WordPress's own authentication. Who you sign in as decides which access tiers you see and whether you can write.

Application Passwords (for apps and scripts)

For headless front ends, mobile apps and server-to-server integrations, use a WordPress Application Password:

1. In wp-admin, open the profile of the user the app should act as. Choose a user whose role matches what the app should see and do: a Subscriber for reading logged-in content, an Editor to write.
2. Under Application Passwords, enter a name for the app and click Add New Application Password.
3. Copy the generated password. WordPress shows it only once.

Send it with HTTP Basic authentication: the username, and the application password.

curl -u "api-reader:xxxx xxxx xxxx xxxx xxxx xxxx" \
  "https://example.com/wp-json/wp/v2/books/123"

WordPress only allows Application Passwords over HTTPS, except on local development sites. Revoke a password from the same profile screen at any time.

Cookie and nonce (for scripts on your own site)

JavaScript running on your own site, for example in wp-admin or a theme, can use the visitor's login cookie, as long as each request includes a nonce:

fetch("https://example.com/wp-json/wp/v2/books?per_page=5", {
  headers: { "X-WP-Nonce": wpApiSettings.nonce },
}).then((response) => response.json())

Note

Opening a REST URL in your browser's address bar sends no nonce, so WordPress treats it as a logged-out request and you only see public fields. That's WordPress's protection against cross-site requests, not a problem with your settings.

Technical details for LLMs

• Auth is WordPress core's: Application Passwords (HTTP Basic) or cookie + X-WP-Nonce (wp_rest nonce). There's no VX-specific token.
• The authenticated user's capabilities select the viewer tier; editor capability on the entity triggers the editor exemption and enables writes.