A plain, step-by-step guide to WordPress REST API application passwords: create one, publish with Basic Auth, test the connection, and fix common errors.
To connect WordPress with an outside tool, you create an Application Password inside WordPress and hand it to the tool, which uses it to talk to the WordPress REST API. The application password lets the tool sign in as you and publish content without ever knowing your real login password. It works over HTTPS, uses standard HTTP Basic Authentication, and can be revoked on its own the moment you stop trusting the connection. This guide walks through the whole path, from what these pieces are to publishing your first post and fixing the errors people hit most.
The WordPress REST API is a built-in interface that lets other software read from and write to your WordPress site over the web. Instead of logging into wp-admin and clicking buttons, an application sends structured requests to web addresses on your site and gets structured answers back, usually in JSON format.
Every WordPress site exposes these addresses under a single root: /wp-json/. Content types sit under a namespace and version, so posts live at /wp-json/wp/v2/posts, pages at /wp-json/wp/v2/pages, and media at /wp-json/wp/v2/media. Reading public data, such as a list of published posts, needs no login. Creating or changing content does, which is where authentication comes in.
This is what makes hands-off publishing possible. A tool can generate an article, format it, attach an image, and send it straight into your site through the REST API, with no copy and paste. If you are still setting up your site, our guide on how to set up a blog on WordPress covers the groundwork first.
Application Passwords are separate, single-purpose credentials that let an application authenticate to your site as one of your users, with that user's permissions, without ever using the user's real password. WordPress added them in version 5.6, released in December 2020, specifically to make authenticated REST API requests safe and simple.
Before this feature existed, connecting an app usually meant either handing over your actual account password or installing an extra authentication plugin. Both were clumsy and risky. Application Passwords solved that in a clean way:
This is the method modern publishing tools rely on. PostSprout, for example, connects to your WordPress site with an Application Password so it can publish daily AI articles for you, and you can revoke that access at any time without touching your account.
Application Passwords are sent using HTTP Basic Authentication, which means the username and password travel inside the request itself, encoded but not encrypted on their own. If that request went over plain HTTP, anyone watching the network could read the credentials. HTTPS wraps the whole request in encryption, so the credentials stay private in transit.
Because of this, WordPress makes Application Passwords available only when requests are served over HTTPS on a live site. If your store does not have a valid SSL certificate, the Application Passwords section will not appear at all. The one exception is a local development environment such as localhost, where WordPress allows them without HTTPS purely for testing.
For any real store, the takeaway is simple: get a valid SSL certificate working first. Most hosts and platforms include one at no cost, and once HTTPS is live, the feature turns on by default.
You create an Application Password from inside your own user profile in wp-admin. The whole process takes about a minute. Follow these steps in order.
You can create as many passwords as you want. The good habit is one per tool, each clearly named, so revoking one never affects the rest.
To publish, your tool sends a POST request to the posts endpoint and includes your username and application password as Basic Auth credentials. The endpoint is:
Basic Auth combines your WordPress username and the application password into a single value, joined by a colon and Base64 encoded, then sent in the request as an Authorization: Basic header. Most tools build that header for you once you paste in the two values. WordPress ignores the spaces in the application password, so you can keep them or remove them.
The request body is JSON. A minimal post to publish looks like this in plain terms: a title, the content, and a status of publish. Set the status to draft instead if you want to review the post before it goes live. You can also pass a category, tags, a featured image ID, and an excerpt in the same request.
If the request succeeds, WordPress returns the new post as JSON, including its ID and public URL. That returned ID is your proof the connection works end to end.
Test authentication before you test publishing, so you can tell the two apart. The quickest check is a read request to an endpoint that requires login, such as:
Send that with your username and application password as Basic Auth. If it returns your user details, your credentials are valid and the REST API is reachable. If it returns an authentication error, the problem is the credentials or the auth header, not your content.
Once that passes, send a test post as a draft. Confirm it appears under Posts in wp-admin, then delete it. When both the read and the write work, the connection is fully live and any real tool can publish through it.
Application Passwords are safe by design, but a few habits keep them that way.
Only connect tools you trust, because an application password acts with your user's full permissions. A reputable service will explain exactly what it does with the access and let you revoke it cleanly.
To revoke access, return to Users, then Profile, and scroll back to the Application Passwords section. Each password you created is listed by its name and the date it was last used. Click Revoke next to the entry you want to remove, and that credential stops working right away. You can also click Revoke all application passwords to invalidate every connection at once.
Revoking a password does not change your login and does not affect any other tool. This is the whole point of the feature: access is disposable. If you switch tools, retire a project, or simply want a clean slate, revoke the old password and issue a fresh one.
Most connection failures come down to a handful of causes. Here is a quick map of what you might see and where the fix usually lies.
| Symptom | Likely cause |
|---|---|
| No Application Passwords section in the profile | Site is not on HTTPS, or the feature is disabled by a plugin or filter |
| 401 Unauthorized | Wrong username or password, or the Authorization header is being stripped |
| 403 Forbidden | The user's role lacks permission, or a security plugin or firewall is blocking the request |
| 404 on /wp-json/ | REST API disabled, or permalinks not set to a pretty structure |
| Works locally but not in production | Missing or expired SSL certificate on the live site |
A very common one is the Authorization header being stripped by the server or a proxy before WordPress ever sees it, which looks like a wrong password even when the credentials are correct. Security plugins and firewalls can also block REST API traffic. For a full walkthrough of these blockers, see our guide on how to fix a WordPress connection when the REST API is disabled by Wordfence or HTTPS issues.
Once you understand Application Passwords, the mechanics stay the same for any tool: create a named password, hand over your username and that password, and the tool publishes through the REST API. The difference between tools is how much of the rest they handle for you.
This is where an automated publisher earns its keep. PostSprout uses exactly the method described here. You paste in your username and an Application Password, and from then on it writes SEO-ready articles, adds images, and publishes them to your WordPress site on a schedule, with no manual steps. Because it authenticates with a revocable application password, you stay in control and can cut off access any time from your profile. Create the password, connect it once, and let the blog run itself.
No, not on a live site. WordPress makes Application Passwords available only when requests are served over HTTPS. The one exception is a local development environment such as localhost, where WordPress allows them without HTTPS for testing. Any production store needs a valid SSL certificate before the feature will appear or work.
Log in to wp-admin, go to Users, then Profile (or Edit User for another account), and scroll to the Application Passwords section near the bottom. If you do not see it, your site is likely not on HTTPS, the feature has been disabled by a plugin or filter, or your role does not permit it.
Yes, that is exactly what the feature is for. An Application Password authenticates as your user with your permissions, but it never exposes your real login password, it can be revoked on its own at any time, and it is stored hashed in the database. Only share it with tools you trust, since it can act with your account's rights.
Yes. WordPress displays the password in groups such as xxxx xxxx xxxx xxxx xxxx xxxx to make it readable, and it ignores the spaces when it checks the value. You can paste it with the spaces or strip them out. Both work the same way.
As many as you want. The recommended practice is one password per application, each with a clear name, so you can revoke a single connection without breaking the others. If you retire a tool or rotate credentials, revoke just that one entry.
The old Basic Authentication plugin sends your real account username and password with every request and is meant only for development and testing. Application Passwords are a built-in production feature that issues a separate, revocable credential per app, so your real password never travels over the wire.
The playbook
The playbook first, then a few short emails to help you publish your first great article, then just the occasional update. No spam, and you can unsubscribe anytime.