You can create a WordPress application password for REST API access by opening your WordPress admin area, navigating to Users, and clicking Profile. Scroll to the Application Passwords section, type a name for your script, and click the button to generate it. WordPress gives you a 24-character string. You use this string along with your normal username in an HTTP Basic Authentication header to securely send requests to the WordPress REST API.
Why do I need an application password for the WordPress REST API?
You need an application password because the WordPress REST API requires authentication to create, edit, or delete content, and sending your actual admin password over an API is a security risk. Application passwords act as unique, revocable tokens. If a script or external app gets compromised, you revoke its specific password without changing your main user password.
You give each integration its own password. You might have one for a mobile app, one for a backup script, and one for a content generator. When you no longer need an integration, you click a single button to revoke its access. The main account remains secure. This keeps your external publishing tools isolated from your primary login credentials.
How do I create a new application password in WordPress?
You generate an application password by going to the Profile screen of the user account you want the API to authenticate as. In the left sidebar of the WordPress dashboard, click Users, then click Profile. If you are an administrator creating a password for another user, click Users, then click Edit on their specific account row.
Scroll down the profile page until you see the Application Passwords section. You will see a text input labeled "New Application Password Name". Type a descriptive name so you remember what this password is for. I usually name it after the script or service making the requests.
Click the "Add New Application Password" button. WordPress will immediately display a 24-character string broken into blocks of four characters. Copy this string right away and save it in your environment variables or password manager. WordPress does not show it to you a second time. If you lose the string, you have to revoke it and generate a new one.
How do I authenticate my REST API requests with Basic Auth?
You authenticate your REST API request by Base64-encoding your WordPress username and the application password separated by a colon, and passing it in the Authorization header. HTTP Basic Auth is the standard protocol for sending these credentials to the wp/v2 REST API.
The format for the unencoded string is username:password. Do not use your email address; use the exact login username for the WordPress account. If your username is admin and your application password is abcd efgh ijkl mnop qrst uvwx, you combine them into admin:abcd efgh ijkl mnop qrst uvwx. You can leave the spaces in the password or remove them. WordPress accepts both formats.
You then Base64 encode that combined string. In a cURL request, you use the --user flag and cURL handles the encoding for you automatically. You run --user "admin:abcd efgh ijkl mnop qrst uvwx". In a programming language like Python or Node.js, you construct an Authorization header with the value Basic followed by the Base64 string.
How do I test the REST API connection?
You test the connection by making a GET request to the /wp-json/wp/v2/users/me endpoint with your new credentials. This endpoint returns your user profile data if the authentication succeeds. Testing against this route is safe because it only reads data and does not modify your live site.
Open your terminal and run a cURL command against your site. Replace the domain, username, and password with your actual details.
curl -X GET https://yourdomain.com/wp-json/wp/v2/users/me \
--user "username:abcd efgh ijkl mnop qrst uvwx"A successful response returns a JSON object containing your user ID, name, and capabilities. A failed response returns a 401 Unauthorized or 403 Forbidden status code. If you see your user data, your application password is valid and ready to use for writing content.
Why is my application password returning an unauthorized error?
Your request will fail with an unauthorized error if your site is not running over HTTPS, or if your web host or a security plugin has disabled application passwords. WordPress core requires an SSL connection to accept application passwords by default.
If you send an API request over plain HTTP, WordPress rejects it. This prevents credentials from being intercepted in plain text over the network. If you are developing locally without an SSL certificate, you have to add a constant to your wp-config.php file to allow insecure connections. You add define( 'WP_ENVIRONMENT_TYPE', 'local' ); to bypass the HTTPS requirement locally, but you should never do this on a live server.
Beyond the HTTPS requirement, many managed WordPress hosts strip Basic Authentication headers at the server level. If your credentials are correct but the API still returns a 401 error, your server might be dropping the Authorization header before it reaches WordPress. If you use Apache, adding CGIPassAuth On or a specific rewrite rule to your .htaccess file usually fixes this. Finally, check your security plugins. Many security tools disable application passwords entirely by default and require you to toggle them back on in their settings.
How do I create a new post via the REST API?
You create a new post by sending a POST request to the /wp-json/wp/v2/posts endpoint with a JSON payload containing your title and content. You include your Basic Authentication header and set the Content-Type header to application/json.
The body of your request requires a few basic fields. At a minimum, you send a title field and a content field. The content field can accept plain text or fully formatted HTML. When you send this request, WordPress creates the post. If you do not specify a status in the payload, WordPress assigns it a status of draft.
The API response will include the new post ID and a link to the drafted content. You parse this JSON response in your script to log the post URL or save the ID for future updates.
How do I set categories and tags via the REST API?
You assign categories and tags to your post by passing arrays of integer IDs to the categories and tags fields in your JSON payload. The WordPress REST API does not accept taxonomy names directly in the post creation endpoint.
Before you can attach a category to a post, you need to know its ID. You find this ID by making a GET request to the /wp-json/wp/v2/categories endpoint. The API returns a list of all categories on your site along with their corresponding integer IDs. You do the same with the /wp-json/wp/v2/tags endpoint to find your tag IDs.
Once you have the integers, you add them to your POST request body. If your API tag has an ID of 12, you include "tags": [12] in your JSON object. You can pass multiple IDs in each array to assign multiple terms to the post. If you send an ID that does not exist, the REST API returns a 400 Bad Request error and the post fails to create.
How do I schedule a future post with the API?
You schedule a post by setting the status field to future and passing a future timestamp to the date_gmt field in your JSON payload. WordPress relies on the date_gmt field to know exactly when the post should go live, regardless of the site's local timezone settings.
You must format this timestamp as a strict ISO 8601 string without timezone offsets. The format is YYYY-MM-DDTHH:MM:SS. For example, 2024-12-01T10:00:00. The status field tells WordPress not to publish the post immediately.
If you pass a future date but set the status to publish, the API might return an error or publish the post right away depending on your specific WordPress version and configuration. Passing the future status triggers the WordPress cron system to automatically transition the article to published when that time arrives.
A full cURL request to schedule a post looks like this.
curl -X POST https://yourdomain.com/wp-json/wp/v2/posts \
--user "username:abcd efgh ijkl mnop qrst uvwx" \
-H "Content-Type: application/json" \
-d '{
"title": "My Scheduled Post",
"content": "This is the HTML content of the post.",
"status": "future",
"date_gmt": "2024-12-01T10:00:00"
}'I use this exact API method to queue up content on my own sites. When AmplifySignal drafts an article from a keyword, it authenticates with an application password and sends a POST request with a future date_gmt to schedule the post on WordPress.
How do I manage external publishing workflows?
You manage external publishing by creating a dedicated user account for the API and granting it only the permissions it needs. If your API script only needs to write posts, create a user with the Author role rather than an Administrator role.
You then generate the application password on that Author account. This limits what the script can do if the credentials leak. The Author role can write and publish posts but cannot alter site settings, install plugins, or modify other users. If you run multiple blogs, you will notice that WordPress handles future dates differently than other platforms. You can read about how to schedule a Ghost post using the editor and the Admin API for a comparison of the payload structures.
Once the post is scheduled in WordPress, you can trigger actions on other platforms. You might want to announce the post on social media once it goes live. You can use the Bluesky API to create a post linking back to your new WordPress article. Since each network handles scheduling differently, coordinating the WordPress publish time with the social media publish time requires tracking the timestamps across your scripts.