Authentication

How the CLI, MCP server, and skill connect to your WordPress site — and how permissions flow through.

NextWave authenticates to your site with a WordPress Application Password over HTTP Basic auth. The tools append /wp-json/nwp/v1 to your site URL and send your username and application password on every request. Whatever that user can do in WordPress, the tools can do — nothing more.

NextWave is self-hosted

There is no central NextWave key or account. You connect directly to your own WordPress install, and your credentials carry your own WordPress permissions. Revoking the application password in WP Admin instantly cuts off access.

Create an Application Password

In WP Admin, open Users → Profile (your own profile, or another user's).
Scroll to the Application Passwords section.
Give it a recognizable name, e.g. nextwave-cli, and click Add New Application Password.
Copy the generated password — shown as xxxx xxxx xxxx xxxx xxxx xxxx with spaces. It is displayed once; store it securely.

Environment variables

The three tools share one connection contract:

Variable	What it is for
`WORDPRESS_SITE_URL`	Your site's base URL; the tools append /wp-json/nwp/v1.
`WORDPRESS_USERNAME`	The user the Application Password belongs to.
`WORDPRESS_APP_PASSWORD`	The WordPress Application Password (keep the spaces; quote it).

bash

export WORDPRESS_SITE_URL=https://members.example.com
export WORDPRESS_USERNAME=jane@example.com
export WORDPRESS_APP_PASSWORD="xxxx xxxx xxxx xxxx xxxx xxxx"

Resolution precedence is flags → environment → profile. Flags like --site, --user, and --profile override the environment, which overrides any named profile stored in ~/.nextwave/config.json. Use --profile to switch between saved sites without re-exporting.

Capabilities & roles

NextWave enforces access with WordPress capabilities. An application password inherits the full capability set of the user it belongs to — so a connection's reach is exactly that user's reach. A request for an operation the user lacks returns 403 rest_forbidden.

Capability	Grants	Typical role
`nwp_manage_members`	Create, edit, and delete members	Administrator / membership manager
`nwp_process_checkins`	Record member check-ins at venues	Front-desk / event staff
`nwp_view_redemptions`	Read benefit redemption history	Staff / reporting
`nwp_manage_redemptions`	Record and edit redemptions	Venue manager
`nwp_approve_redemptions`	Approve or reject pending redemptions	Manager / supervisor
`nwp_manage_settings`	Change plugin configuration	Administrator

Verify your connection

Run the doctor to check the site URL, credentials, and REST reachability in one shot:

bash

$ nwp doctor

Then confirm exactly who you're authenticated as:

bash

$ nwp whoami --output json

Rotation & hygiene

Revoke any application password from Users → Profile the moment it's no longer needed — it takes effect immediately.
Rotate by adding a new application password first, switching your tools over, then revoking the old one — zero downtime.
A password only ever carries that one user's capabilities; it cannot escalate.
Never commit credentials to source control or paste them into shared configs.
Always quote the password so the shell preserves its spaces.
Follow least privilege: create a dedicated user with only the capabilities the integration needs rather than reusing an admin login.

Hitting a 401 or rest_forbidden? See Troubleshooting to map the response to a fix.