A publishing tool needs to send information to WordPress, so somebody gives it an administrator’s usual password. The connection works, but ownership soon becomes unclear. Which service uses the credential? What happens when the person leaves? December’s WordPress 5.6 release brings application passwords into that conversation, offering a more deliberate way to identify and manage an API connection.
Give the connection its own credential
The integration guide describes application passwords as separate credentials for authenticated API use, with the ability to revoke them individually. They are not a replacement for a person’s ordinary interactive login. The associated user account still matters because it determines the permissions available to the connection.
That distinction is useful for a business. A named integration can be discussed and retired without treating one person’s main password as a shared operational asset. The credential remains sensitive, and the connection still needs a clear purpose and an appropriate account.
Begin with the work the service must perform
Consider a content workflow in which an internal publishing system sends approved articles to WordPress. Does it need to create drafts, upload media or publish directly? Those are different responsibilities. Choose permissions around the required task rather than automatically giving the integration the broadest possible account.
Write down who owns the service and who can disable it. Include what happens when the external tool is unavailable. A useful integration should not turn the website into a system that only an absent supplier can operate.
Keep credentials out of ordinary content
The connection should use HTTPS and store its credential through an appropriate protected configuration mechanism. It should not place the secret in a public script, an article body or a screenshot passed around for support. A separate credential is easier to manage, but it is not harmless if exposed.
Test the intended operation on a protected environment and verify the resulting content and media. Then test revocation. A team should know that removing the credential stops the connection, and it should understand how to replace it without leaving several forgotten credentials active.
Make the operational record readable
A short integration record can name the service, its responsible account, the work it performs and the person who reviews it. Keep the secret itself out of that general record. The aim is to make the relationship understandable without spreading the credential to everyone who needs to know the integration exists.
Keep the task, its owner and the way to revoke access visible in the integration record. A connection that can be identified and stopped cleanly is easier to support than a shared credential whose purpose nobody remembers. Application passwords supply a building block; the team still designs the workflow.
