Application passwords act with the capabilities of their associated WordPress user. They are not automatically restricted to one endpoint or one small task. Use an account with only the permissions the integration requires, and review whether a dedicated integration user is appropriate.

Use HTTPS and the integration's documented authentication method. Application passwords are intended for supported API requests, not as a replacement password for ordinary browser login.

1. Open the intended user's profile through an authorised account and locate Application Passwords where available.
2. Enter a descriptive name identifying the application and purpose.
3. Generate the password and copy it directly into the approved integration's secure credential storage.
4. Record the credential's label and owner without recording the secret in a public ticket or document.
5. Run a limited test and confirm the integration can perform only its intended work.

After creating a separate application password for an appropriately scoped integration user, test a read-only identity endpoint. Supply only the username to curl so it prompts for the password instead of placing that secret in the command line.

curl --silent --show-error --fail-with-body \
  --connect-timeout 3 --max-time 10 \
  --user 'integration_reader' \
  'https://example.com/wp-json/wp/v2/users/me?_fields=id,slug'

At the prompt, enter the integration’s application password, not the ordinary browser-login password. Replace the username and URL with the verified account and canonical HTTPS site. Do not add a redirect-following or insecure-TLS option to conceal an unexpected response.

Expected result: The returned ID identifies the intended integration user. Revoking that one application password causes this request to fail, while unrelated approved integrations keep their separately managed credentials.

Return to the user's application-password list to review available usage information. Revoke the specific credential when a supplier leaves, an integration is retired or the secret may have been exposed. Test that requests using the revoked credential fail as expected.

Do not assume changing the user's ordinary password automatically performs every integration cleanup you need. Review application credentials explicitly and rotate them through a planned process so legitimate jobs can continue with the replacement.

If the section is unavailable, check HTTPS, user permissions and site security policies. If authentication fails, verify the username, site URL and whether a security layer strips or blocks the required authorisation header.

Never place the password in a public URL, browser screenshot or command example committed to source control. Sanitise request logs before sharing them. If an integration asks for Administrator access but only reads public posts, question that requirement and use its official documentation to establish the actual minimum scope.

• Reviewing WordPress administrator accounts
• Troubleshooting a failed WordPress REST API request
• Changing your WordPress account password
• Changing the public display name of a WordPress user

• REST API authentication
• Application passwords guide

• curl command options