This guide shows how to let an n8n workflow read and answer WordPress comments through the REST API using an Application Password and a Basic Auth credential. It is based on a comment-reply workflow I built and ran against my own WordPress site, so the endpoints and settings below are the ones that workflow actually calls.
What you need
- A WordPress site served over HTTPS. According to the WordPress core integration guide, Application Passwords are available by default only on sites served over SSL/HTTPS.
- A WordPress user that is allowed to moderate comments.
- An n8n instance. I used n8n 2.8.3, self-hosted.
Step 1. Create an Application Password in WordPress
- In wp-admin, open the profile (Edit User screen) of the user the workflow will act as.
- Find the Application Passwords section, give the new password a name such as the name of the workflow, and create it.
- Copy the generated password right away and keep it for the next step. The core guide does not say whether it can be shown again, so treat it as visible once.
Use an Application Password instead of the account password. It can be revoked on its own from the same section without changing your login. The core guide notes that the Last Used column helps you spot passwords that are safe to revoke.
Step 2. Create the credential in n8n
- In n8n, create a new credential of type Basic Auth.
- Set the user to your WordPress username and the password to the Application Password.
- Save it. The password lives only in the n8n credential, not in the workflow JSON.
Step 3. Point the HTTP Request nodes at the REST API
For every WordPress call I used an HTTP Request node with these settings.
- Authentication: Generic Credential Type
- Generic Auth Type: Basic Auth, with the credential from step 2
- URL: your site address plus
/wp-json/wp/v2/...
Credentials are sent as HTTP Basic Auth over HTTPS, which is the scheme the core guide describes.
The six WordPress calls in the workflow
| Purpose | Method and path | Notes |
|---|---|---|
| Check that authentication works | GET /wp-json/wp/v2/users/me | I request only _fields=id,name. A response with your user id and name means the credential works. |
| List comments waiting for moderation | GET /wp-json/wp/v2/comments | Query status=hold, per_page=20, plus an orderby. |
| List approved comments | GET /wp-json/wp/v2/comments | Same path with status=approve. |
| Read the post a comment belongs to | GET /wp-json/wp/v2/posts/{post id} | I request _fields=id,title,content,link so the answer can use the article text. |
| Approve the original comment | POST /wp-json/wp/v2/comments/{comment id} | JSON body with status set to approved. The reference page lists status as a string without listing its values, so check the value on your own site. |
| Publish the reply | POST /wp-json/wp/v2/comments | JSON body with post, parent and content. |
The approve call body is just this.
{ "status": "approved" }The comment endpoints and their arguments are listed in the WordPress REST API comments reference.
How I tested it
I ran the workflow by hand on 2026-10-07 against my own site. The first node after the trigger and config is the users/me call, which returns the id and name of the authenticated user. The workflow uses that id to skip comments written by the same account, so a working credential shows up right there.
My test comments were created with an admin tool, because the Jetpack comment module on my site sends visitors through a WordPress.com login. I ran three cases.
- A normal question about an article: the workflow drafted a reply, sent it to Telegram, and after I approved it the original comment was approved and the reply was posted.
- A question the article does not cover: the draft said the article does not cover it and asked for the error text, version, operating system, and command output.
- An advertising-style spam comment: it was marked SKIP, only a skip notice reached Telegram, and nothing was published on the site.
The full workflow, including the Telegram approval step, is described in my Korean write-up.
Security notes
- Keep the Application Password only in the n8n credential. Do not paste it into a workflow JSON you share or into a chat.
- Create one Application Password per integration so you can revoke it without touching anything else.
- Do not turn on Application Passwords over plain HTTP. The core guide warns that passwords could then be seen by an attacker on the network.
What I did not test
- I did not test what the API returns for a wrong or revoked password.
- I ran the workflow as the site owner account. I did not test a user with a lower role.
- I did not test other hosting setups or security plugins that might block REST requests.
Sources: WordPress core, Application Passwords integration guide and WordPress REST API handbook, Comments.