Editorial illustration; the tool, credential and API labels are representative, not a live WordPress dashboard.
An external tool may need to publish a post, upload media, read content or run a report against WordPress. The dangerous shortcut is to give that tool your normal administrator password. The safer pattern is a separate Application Password created for one user and one integration, then revoked when it is no longer needed.
WordPress describes Application Passwords as credentials for programmatic access, not for interactive wp-admin logins. They are individually revocable and shown only once when created. That makes them useful, but only if you also scope the user, protect the secret and test what the integration can actually do.
Summary
- Use a dedicated, least-privileged WordPress user when the integration does not need administration.
- Create one named Application Password over HTTPS, store it as a secret, and test a harmless API call.
- Monitor usage and revoke the credential when the tool is retired, replaced, or suspected of leaking.
Decide whether you need one
First define the job. “Connect analytics” is vague; “read published posts once per hour” is testable. Write down the endpoint, HTTP method, expected frequency and whether the tool needs to create, edit or delete content.
The WordPress REST API already exposes public content anonymously in many cases. Do not add an authenticated credential just to read information that the public site already provides. Authentication is for protected content or actions that require a user’s capabilities.
If a vendor asks for your full administrator password, ask whether it supports the WordPress REST API and Application Passwords. If it cannot explain how it stores and revokes credentials, treat that as a product-risk question rather than a setup inconvenience.
A safer setup workflow
1. Create the smallest suitable user
Use a dedicated account for the integration where practical. Choose a role based on the required action. A reporting tool that only reads public posts should not receive an administrator account. A publishing tool may need an author or editor capability, but confirm what it actually performs.
Do not share a human administrator’s account with a script. Separate accounts make logs and revocation more understandable.
2. Confirm HTTPS and the site URL
Application Passwords are intended for HTTPS requests by default. Check that the public site uses the correct HTTPS address and that the WordPress installation detects HTTPS correctly. Do not put a credential in a URL or send it to a staging site you do not trust.
3. Create a named Application Password
Open the user profile in Users > Profile or edit the relevant user. Find Application Passwords, enter a descriptive name such as weekly-reporting-tool or media-import-staging, and generate it.
Copy the generated value immediately. WordPress shows the password only once. Store it in the integration’s secret store or environment variable, not in a repository, spreadsheet or screenshot.
Create one credential per tool. If three tools share one password, revoking one tool also breaks the other two and hides which integration is responsible for a request.
4. Test with a harmless request
Start with an identity or read-only request. For example, a controlled test can call /wp-json/wp/v2/users/me using the integration’s username and Application Password. Use a test site where possible, and ensure the request uses HTTPS.
Do not paste a real credential into a shell history, issue tracker or support chat. Replace the placeholder in examples locally and clear any temporary files after testing.
5. Test the exact capability boundary
An authentication success does not prove that the workflow is safe. Try the smallest real action in staging: read a post, create a clearly marked draft, or upload a test image. Confirm that an action the integration should not perform is denied.
This is where the WordPress role and capability model matters. A tool that only needs to create drafts should not be tested with publish or user-management permissions.
6. Add monitoring and a removal date
Give the credential a name that explains its owner. Review its last-used information in the user profile and keep a short record of where it is deployed. Add a reminder to revoke it when a vendor contract ends, a pipeline is replaced or a leak is suspected.
Revocation is per Application Password. You do not need to change the user’s main password just to remove one retired integration, unless the main password may also have been exposed.
What a responsible integration should explain
Before approving a connection, ask the vendor five concrete questions:
- Which REST API endpoints will it call?
- Does it read, create, edit, publish or delete content?
- Where is the credential stored, and who can retrieve it?
- How do you disable the connection without deleting the whole account?
- What happens when the site returns an error or the credential is revoked?
The answers should match your written job definition. If a reporting tool cannot explain why it needs write access, do not expand permissions just to complete setup. A connection that fails safely is easier to repair than one that succeeds with unnecessary authority.
A simple rotation and removal checklist
When a tool changes hands or is replaced, pause its jobs, confirm the replacement works, then revoke the old Application Password. Search deployment settings and secret stores for the old name, but do not paste the secret into tickets while checking. Review the user’s sessions and connected services if the credential may have been exposed alongside other account data.
Keep the user account only if it has another documented purpose. Otherwise, disable or remove the account according to your site’s change process after confirming no other workflow depends on it.
Example: a nightly content report
Suppose a reporting script needs to read post titles and dates every night. It probably does not need to publish posts, manage plugins or edit users. Give it a dedicated user with the minimum read capability that the chosen endpoint requires, create a named credential, and test a read-only request.
If the vendor later asks for write access, pause and redefine the job. The change should be reviewed as an access expansion, not accepted as a routine update.
Mistakes to avoid
- Putting the Application Password in JavaScript sent to every browser.
- Committing a
.envfile or curl command containing the real secret. - Reusing one credential across staging, production and unrelated tools.
- Giving an integration administrator access because it is convenient.
- Assuming a successful login means the requested action is appropriately limited.
- Forgetting to revoke a credential after a migration.
For related access design, see WordPress roles and capabilities and how to protect an admin login.
My Take
Application Passwords are valuable because they make integration access specific and reversible. They do not make a broad user role safe by themselves. The best setup is a small contract: one named tool, one suitable user, one secret, one tested endpoint and a clear revocation owner.
Conclusion
Define the integration’s exact task, create the smallest suitable WordPress user, generate one named Application Password over HTTPS, test the boundary, and monitor its use. If the tool disappears, revoke its credential promptly.