WordPress Application Passwords: Connect, Test, and Revoke

WordPress & Web Development / Integrations / Practical guide

A WordPress application password lets a trusted app authenticate to your site’s APIs without receiving your main login password. Create a separate credential for each integration, choose the WordPress account deliberately, test the connection, and revoke the credential when the integration ends.

The important distinction is between recognizing an account and limiting what it can do. An application password is not automatically a read-only key or permission to perform just the task written in its name.

01 / API authentication is separate from dashboard login

WordPress describes application passwords as per-user API credentials that are stored hashed, shown once when created, and individually revocable. They cannot be used for interactive sign-in at wp-login.php. The official application passwords handbook explains their purpose and lifecycle.

Use them only when the integration supports this authentication method. Some products use their own authorization flow or credentials. Follow the product’s documented connection process rather than pasting a WordPress password into every field labelled “API key.”

For example, “Monthly report — production” is a useful hypothetical label. It does not establish that the credential can only read reports or only run once a month.

02 / Choose the account before generating the secret

WordPress uses roles and capabilities to control actions. Its roles documentation distinguishes tasks such as uploading files, editing other people’s posts, publishing, and managing site options. Plugins and custom roles can affect the permissions on a particular site.

Write down what the tool actually needs. “Manage content” is too vague. A better requirement might be “create its own draft posts and upload images, without publishing or editing other authors’ work.” Then ask the site administrator to select or configure an account that satisfies that requirement.

The built-in authentication function authenticates the associated user. Do not assume that creating another password for a powerful account narrows that user’s permissions. Any additional per-integration restrictions must be documented and verified in your site’s implementation.

• Prefer a dedicated integration account when it improves accountability and permission management.
• Record whether the tool can publish, delete, or change existing content.
• Separate production and staging connections in your records.
• Do not grant Administrator merely to make an unexplained error disappear.

If your required combination of actions does not match a standard role, resolve that with the administrator before connecting the tool. A password name cannot substitute for capability checks.

03 / Create one credential and store it immediately

Open the profile for the intended WordPress user. You can reach your own profile through the Users menu or your name in the dashboard toolbar, as described in the profile screen documentation.

1. Find Application Passwords on the user’s profile.
2. Enter a descriptive integration name, including an environment or purpose when useful.
3. Choose Add New Application Password and copy the generated value.
4. Store it in the integration’s protected credential field or an approved secret store.
5. Record the site, username, label, purpose, responsible person, and review date separately from the secret.

WordPress’s integration guide covers manual creation and management. Displayed spaces are for readability and may be included or omitted. If you lose the value, create a replacement and retire the unused credential instead of expecting to reveal the original again.

Keep passwords out of screenshots, shared documents, support tickets, and source code. If someone needs to troubleshoot a connection, provide the credential’s label and sanitized error details rather than the secret itself.

04 / Verify identity before allowing content changes

The WordPress REST authentication handbook documents Basic authentication with application passwords over HTTPS. The client supplies the WordPress username and generated application password; an ordinary browser session is a different authentication path.

If you use curl locally, this hypothetical request reads the current user. Replace the domain and username with your own authorized site and account:

curl --user "integration_user" "https://example.com/wp-json/wp/v2/users/me"

With only a username supplied, curl prompts for the password. Enter the application password at that prompt. The curl manual documents this behavior; it avoids placing the secret directly in the command text. Use the actual curl program, such as curl.exe where needed on Windows.

The WordPress users endpoint reference documents the current-user route. Confirm that the returned user is the intended integration identity. This check verifies authentication, not every capability the app requires.

Next, test the tool’s required operation with a harmless sample, preferably in staging. For a publishing integration, create a clearly labelled draft and inspect its author, status, content, and media before allowing a production workflow. Use Ryvenora’s staging-to-live checklist when broader site changes are involved.

05 / Diagnose the failure without widening access blindly

If the section is missing, availability is a separate question from the user’s publishing permissions. WordPress’s availability function reference says the default support covers SSL sites and local environments, and filters can change availability. There is also a per-user availability check.

A failed response alone does not prove the password is wrong. WordPress’s handbook also notes that clients or proxies can strip the Authorization header. Ask the host or integration developer to trace that path when appropriate. Keep credentials and sensitive response fields out of diagnostic reports.

06 / Treat Last Used as a clue, not a request log

Application password usage metadata can help identify forgotten connections. However, WordPress core’s usage recording method updates activity at most once a day. It records a last-used timestamp and IP address; it is not a complete list of API calls.

Do not conclude that an integration stopped merely because the displayed timestamp did not change during a short test. Pair that information with the tool’s job history, actual results, and appropriate server-side logs.

Maintain a small register that answers: who owns this connection, what does it do, when was it last reviewed, and how do we stop it? Clear names make that register useful when staff, vendors, or workflows change.

07 / Rotate or revoke with a clear verification step

You can revoke an individual credential in the same profile section. The administration handbook recommends one credential per integration and rotation after a suspected leak. A separate password makes it easier to identify and stop one connection.

For a planned replacement, use this operational sequence:

• Identify the exact label and account currently used by the tool.
• Create a replacement and update the tool’s protected credential storage.
• Run an identity check and the intended sample operation with the replacement.
• Revoke the old credential and confirm an authenticated request with it fails.
• Confirm the replacement still works and update your integration register.

If a credential may have leaked, prioritize revoking it and investigating the activity rather than preserving an uninterrupted connection at all costs. Revocation blocks future authentication with that password; it does not undo posts, uploads, or other actions already completed. Inspect affected work separately.

For an integration being retired, stop its scheduled work as well as revoking its credential. Otherwise, recurring failures may continue to generate alerts and obscure other operational problems.

Frequently asked questions