How to Connect WordPress with the REST API and Application Passwords

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.

What is the WordPress REST API?

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.

What are Application Passwords, and why do they exist?

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:

• They never expose your real password. The app only ever sees the application password, not your account login.
• They are scoped per application. You create one for each tool and give it a clear name, so you always know which connection is which.
• They are individually revocable. You can cut off one tool without changing your password or breaking any other connection.
• They are stored hashed. WordPress keeps only a hashed version in the database and shows you the plain value once, at creation time.

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.

Why do Application Passwords require HTTPS?

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.

How do you create an Application Password in WordPress?

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.

1. Confirm HTTPS is active. Load your site with https:// and check that the certificate is valid. Without it, the section below will be missing.
2. Log in as the publishing user. Sign in with an account that can create posts, such as an Editor or Administrator. The app will act with this user's role.
3. Open your profile. Go to Users, then Profile in the left menu. To set up a password for a different account, open Users, pick the person, and click Edit User.
4. Scroll to Application Passwords. Find the panel near the bottom of the profile screen.
5. Name the application. Enter a descriptive label such as the tool's name, then click Add New Application Password.
6. Copy the password now. WordPress generates a 24-character value shown in groups like xxxx xxxx xxxx xxxx xxxx xxxx. It is displayed only once, so copy it immediately. If you lose it, you cannot get it back and must generate a new one.

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.

How do you use an Application Password to publish a post?

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:

• https://yoursite.com/wp-json/wp/v2/posts

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.

How do you test the connection?

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:

• https://yoursite.com/wp-json/wp/v2/users/me

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.

What are the security best practices?

Application Passwords are safe by design, but a few habits keep them that way.

• Use one password per application. A clear name and a dedicated credential mean you can revoke a single tool without collateral damage.
• Give the app the lowest role it needs. If a tool only publishes posts, connect it as an Editor rather than an Administrator so it cannot touch settings or users.
• Store the password like a secret. Treat it the way you would treat an API key. Do not paste it into public documents, tickets, or chat logs.
• Rotate when in doubt. If you suspect a password leaked, revoke it and generate a new one. Nothing else on your account has to change.
• Keep HTTPS healthy. An expired certificate can break the connection and expose credentials, so watch your SSL renewal.

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.

How do you revoke an Application Password?

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.

What are the most common Application Password errors?

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.

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.

Connecting WordPress the hands-off way

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.