Review and approve pending WordPress posts with Gemini and Slack

When a writer submits a post for review, WordPress sends its ID to one n8n webhook. In n8n, the post is checked against your rules and reviewed by Gemini. An editor then gets it in Slack with one Review button: publish it, or send it back with a note that goes to the author by email.

Why it goes through n8n

WordPress has a Pending status but nothing that acts on it: someone has to remember to look. This build sends the moment of submission out, so the review starts right away and the editor never has to check the posts list.

n8n holds the WordPress, Gemini, Slack and email connections, so WordPress only ever talks to one URL. Change the house style, the word count or the review channel in n8n, and nothing changes in WordPress.

What you need first

1. In n8n, import the template Review and approve pending WordPress posts with Gemini and Slack. In its Settings node, set the review channel, your house style, the minimum word count, whether a featured image or excerpt is required, how long the editor has to answer and the sender address.
2. Connect WordPress (an administrator or editor account with an application password, because a pending post is not public), Gemini (an API key from Google AI Studio), Slack (a bot token with chat:write, invited to the review channel) and SMTP inside n8n.
3. Open the Review Request Webhook node, add a Header Auth credential with the name X-Webhook-Token and a long random token as the value, and copy the node's production URL.
4. Import this build. The webhook arrives disabled: replace its endpoint URL with that production URL, give the import the same token when it asks for the credential, then enable it. The token lives in the Credentials Vault and is never part of a shared build.

What gets sent

{
  "post_id": 123
}

Only the ID travels. wp_after_insert_post hands over the post ID, the post, an update flag and the post as it was before the save; args.0 becomes post_id and nothing else is sent. n8n reads the post and its author back through the WordPress API, so it always sees the saved version.

Three conditions decide when it fires: args.1.post_status equals pending, args.3.post_status does not equal pending, and args.1.post_type equals post. A post fires once, when it moves to Pending. Saving it again while it waits, and revisions, send nothing.

Why this hook

The block editor saves the post first and its featured image, categories and custom fields after. transition_post_status and save_post fire in between, so n8n would read a post with no featured image yet. wp_after_insert_post fires last, when everything is stored.

If a delivery fails

Delivery is asynchronous, so the writer never waits on n8n. A failed POST is retried 5 times (1m, 2m, 4m, 8m) and every attempt is kept in the delivery log. If n8n was down for the whole ladder, hit Replay once it's back and the post goes to review as if it had just been submitted.

A 200 from the webhook node only means n8n accepted the post. Check n8n's own execution list to see what happened next. If Gemini is down, the editor still gets the post, marked for review by hand. Before publishing, n8n checks the post is still pending, so a post someone already published by hand is left alone.