Application Passwords interested me because they made small WordPress REST API integrations feel more practical.
Before that, authenticated API work in WordPress often meant choosing between approaches that felt slightly awkward for small internal tools. Cookie authentication worked inside WordPress, but not neatly from an external script. OAuth-style approaches could be more than the project needed. Sharing a normal user password with a script was not something I wanted to do.
Starting With A Small Use Case
The use case I had in mind was simple. I wanted a small script to create draft posts through the REST API. Nothing public-facing, nothing complicated, just a controlled way to send structured content into WordPress without logging into the admin screen every time.
The important decision was creating a dedicated user with only the permissions the script needed. I did not want an integration authenticating as a full administrator unless there was a very good reason. The smaller the permission set, the safer the integration feels.
Creating The Password
Inside WordPress, the password is generated from the user profile. I gave it a name that described the integration, copied it once and stored it somewhere appropriate for the local script. The fact that it could be revoked later mattered. If the script was no longer needed, I could remove that one credential without changing the user’s normal login password.
Making A Test Request
The first request was deliberately simple. I wanted to confirm authentication before trying to create anything.
curl --user "editor@example.com:xxxx xxxx xxxx xxxx xxxx xxxx" https://example.com/wp-json/wp/v2/users/meOnce that returned the expected user, I moved on to creating a draft post.
curl --user "editor@example.com:xxxx xxxx xxxx xxxx xxxx xxxx" -X POST https://example.com/wp-json/wp/v2/posts -H "Content-Type: application/json" -d '{
"title": "Imported draft article",
"status": "draft",
"content": "<!-- wp:paragraph --><p>Draft content created through the API.</p><!-- /wp:paragraph -->"
}'Why It Felt Useful
The useful part was not that the API suddenly became new. The useful part was that authentication became easier to explain and control. A script could have its own named credential, and that credential could be removed without affecting the user’s main account.
This also made local automation less messy. If I needed to generate draft content, test imports or connect a small internal tool, I had a clear route into WordPress that did not require building a whole authentication system first.
What I Stayed Careful About
Application Passwords are still credentials, so they need to be treated carefully. I would not commit them into a repository, paste them into shared documentation or use them from insecure environments. I also preferred using HTTPS and keeping permissions limited to the job the integration needed to perform.
Retrospectively, this felt like one of those WordPress improvements that made a lot of quiet practical work easier. It did not change how most visitors experienced a website, but it made small developer workflows cleaner, especially where the REST API was already the right tool for the job.