WordPress Application Passwords: How to Set Up, Secure and Rotate Credentials for Integrations

Integrations, scripts and automation tools often need to communicate with WordPress without using the main password of an administrator or another user. Sharing that primary credential makes ownership and revocation more difficult: disabling one workflow may require changing the password used for normal site access. WordPress Application Passwords address this specific operational problem by providing separate credentials for programmatic access.

An Application Password is associated with a WordPress user, can be revoked individually and is intended for REST API requests, scripts and applications rather than interactive wp-admin login. This guide explains how to prepare an integration, create a credential, use it through HTTPS, store and rotate it, manage it with WP-CLI and investigate common 401 or 403 responses. It also distinguishes WordPress-documented behavior from organization-specific recommendations, such as the choice of a secret store and the rotation schedule.

What WordPress Application Passwords Are—and Are Not

Application Password versus the primary user password

A WordPress Application Password is a separate credential tied to a particular WordPress user account. Its purpose is programmatic authentication, for example when a script, REST API integration or application sends an authenticated request. It is not intended for interactive login to wp-admin through wp-login.php, so it should not be treated as an alternative password for people signing in through the normal form.

The main practical difference is lifecycle control. An individual Application Password can be revoked without changing the user’s primary password. If a particular integration is retired or its credential is suspected of being exposed, that one credential can be disabled while the user’s normal login remains unchanged. However, the Application Password does not create permission isolation beyond the associated account. Its effective access remains connected to the capabilities of that WordPress user, so the selected account should have only the access required by the workflow where that is possible.

Before You Create a Credential

Integration and transport checks

First confirm that the specific external service or connector supports WordPress REST API authentication with Application Passwords. Compatibility cannot be assumed for every automation platform. The client must also preserve the HTTP Authorization header. A reverse proxy or another component in the request path must not remove it before the request reaches WordPress.

Use HTTPS for every authenticated request and verify that WordPress correctly recognizes the secure protocol. This matters particularly when HTTPS is terminated by a reverse proxy or when redirects are present. Basic Authentication credentials can be intercepted if they travel without encryption. Before generation, also select an account whose capabilities fit the integration and choose a descriptive name that identifies the service, script or workflow.

• Confirm support for WordPress REST API authentication in the specific connector.
• Verify HTTPS across the complete request path, including proxy handling and redirects.
• Select a WordPress user with appropriate capabilities for the process.
• Choose an integration-specific name that will remain useful during later review.

How to Create an Application Password in wp-admin

The wp-admin creation workflow

In wp-admin, open Users → Profile. Alternatively, go to Users → All Users → Edit and open the profile of the relevant user. Find the Application Passwords section and enter a descriptive name for the integration. The name should identify one concrete service or workflow rather than a broad, unclear purpose.

1. Open the profile of the WordPress user who will be associated with the integration.
2. In Application Passwords, enter the descriptive integration name.
3. Generate the Application Password.
4. Copy the generated value immediately into a protected credential store.
5. Configure the external tool with the WordPress username and generated Application Password.
6. Test a controlled authenticated request over HTTPS before enabling automation.

WordPress displays the generated value only when it is created. It will not be shown again in the profile, so do not close the screen before storing it safely. Never place a real credential in a screenshot, public ticket, repository, client-side JavaScript, email or unsecured configuration file. The external tool must use the Application Password, not the user’s normal login password.

Using Application Passwords with REST API Integrations

Authentication flow and request handling

Application Passwords are typically sent through HTTP Basic Authentication. The request uses the WordPress username together with the generated Application Password. This lets a script or connector authenticate programmatically without receiving the user’s primary password.

HTTPS is an essential part of this flow. The request should remain encrypted from the client through proxies and other components until it reaches the site. The client and any reverse proxy must preserve the Authorization header. Do not move authentication headers into browser-side code or expose them in public logs. Also verify the behavior of the particular connector: the official feature does not establish that every third-party automation service supports it or forwards the header correctly.

Secure Storage, Rotation and Revocation

A repeatable credential-lifecycle process

Treat every Application Password as a secret. Create one credential per integration or application instead of reusing one value across unrelated services. This makes ownership clearer and allows one workflow to be disabled without disrupting others. Store the value in a protected secret or credential store appropriate to the platform. The choice of a specific product or storage system is an operational decision, not a universal WordPress requirement.

Review the Application Passwords section in the user profile. It can show existing credentials by name and available usage metadata, such as the last-used time and last IP. This information can support an operational review, although it should not replace relevant server logs or investigation of the integration itself.

• Revoke credentials for integrations that are no longer needed.
• Document the integration owner and the process for replacing its credential.
• Define an organization-specific rotation schedule.
• After suspected exposure, treat the credential as compromised and revoke it promptly.
• Create a replacement, update the integration and review available usage metadata and server logs.

WordPress documentation recommends revoking unused credentials and rotating them according to a schedule or after suspected exposure. It does not prescribe one universal rotation interval. Similarly, documenting ownership and choosing a secrets manager are practical governance recommendations rather than mandatory WordPress settings.

Managing Credentials with WP-CLI

Creation, inspection and deletion

Administrators and agencies using SSH can manage Application Passwords with WP-CLI. The documented command group supports creating, listing, retrieving, updating and deleting credentials. It can also check whether a credential exists and record usage. Creation can output the generated value once, which is useful for controlled automation, but that output must be treated as secret data.

Use WP-CLI in an environment with restricted access and protect command output and shell history. Do not place real credentials in shared commands, examples or logs. Listing and inspection can help identify credentials by name and review their state, while deletion provides a way to revoke a credential without changing the user’s primary password.

• Create a credential for the specific user and integration.
• Inspect or list credentials when performing an administrative review.
• Use supported update or usage operations when the workflow requires them.
• Delete credentials that must be revoked.
• Protect terminal output, shell history and administrative access.

Troubleshooting 401 and 403 Errors

Documented checks first

When an integration returns 401 or 403, begin with the checks directly related to Application Passwords. Confirm that the request uses HTTPS and that WordPress correctly detects HTTPS. This is especially important behind a reverse proxy. Then verify that the client sends the generated Application Password, not the user’s ordinary password.

Next check whether a security plugin, must-use plugin or custom code has disabled Application Passwords. Finally, verify that the client and proxy preserve the HTTP Authorization header. A missing header can make valid credentials appear to be absent. Do not reveal the credential while collecting request details or preparing a support report.

Environment-specific checks

If the documented checks pass, continue with diagnostics specific to the environment. Examine the REST endpoint being called and confirm that the associated user has the capabilities needed for that operation. Review redirects, hosting firewall rules, WAF behavior and reverse-proxy handling. Also inspect the authentication settings of the particular third-party connector.

These additional checks are practical troubleshooting areas, not a claim that every 401 or 403 has the same cause. Endpoint-specific behavior, account capabilities, host-level filtering and connector configuration may all affect the result. Keep tests controlled, use HTTPS and avoid copying secrets into logs or tickets.

Security Checklist Before Going Live

Go-live and maintenance checklist

Before enabling an integration, confirm that the credential lifecycle is understandable to the site owner, freelancer or agency responsible for maintenance. A descriptive name should make the purpose visible in the user profile. Separate credentials should make it possible to retire one workflow without changing unrelated access.

• Use a separate Application Password for each integration or workflow.
• Associate the credential with a WordPress user whose capabilities fit the process.
• Confirm HTTPS and correct preservation of the Authorization header.
• Store the secret outside public code, browser-side code, screenshots and logs.
• Document the integration owner and replacement procedure.
• Set an organization-specific rotation schedule.
• Review available usage metadata and relevant server logs.
• Revoke credentials for withdrawn services or after suspected exposure.

This checklist does not guarantee compatibility with every automation tool or provide complete protection against every hosting problem. It establishes a practical baseline: use the documented authentication model, protect the transport and secret, limit the associated user’s access where appropriate, and maintain the credential throughout its lifecycle.

WordPress Application Passwords separate programmatic access from the user’s primary login password, while remaining connected to that user’s capabilities. Create a named credential for each integration, use HTTPS, protect the value immediately after generation and verify that the Authorization header survives the complete request path. Review usage information, revoke credentials that are no longer needed and replace any credential that may have been exposed. The storage method and rotation interval should follow your organization’s operational policy rather than an assumed universal WordPress rule. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.