Sending a webhook when a post is published (Pro)

This is the reverse of the sections above. Those bring information in and turn it into a post. This sends a webhook out, the moment a post is published — so something else, such as an automation platform that posts to WhatsApp or Slack, can react.

It fires for any post, page or custom post type becoming published — whether created by this plugin’s own publishing, above, or written normally in the WordPress editor.

Setting it up

1. Go to Deftmind Hookwright → Publishing.
2. Scroll to Post publish webhooks. There is a block for every post type on your site.
3. Tick Send a webhook the first time a post of this type is published.
4. Enter the Webhook URL.
5. Under Send, tick at least one item.
6. Click Save Changes.

Testing it before you publish anything

Beside the address there is a Test webhook button. Press it and one real sample request goes to that address straight away, and you are shown three things:

• The exact body it sent, so you can build the receiving end against real data rather than guessing.
• The signature it used, if you have set a signing secret — which lets you prove your signature check works before a real post depends on it.
• Whatever your endpoint replied, including the status code and how long it took.

It uses whatever is currently typed on the screen, even if you have not saved yet, so you can try an address before committing to it. It creates no post and changes nothing on your site.

The sample looks exactly like a real message with one addition: "test": true at the top. Your automation can use that to ignore test messages, or to branch to a safe path while you are still building.

Overriding it for one post

• Use the site default for this post type — the normal behaviour.
• Send this post to a different URL — administrators only.
• Do not send this post — opts just this one post out.

When it fires

Once, the moment a post is first published. Editing an already-published post does not send it again, and neither does un-publishing and re-publishing it.

What is sent

Whichever fields you ticked, plus three things that are always included: the post’s web address (permalink), its numeric id (post_id) and its type (post_type).

{
  "post_id": 123,
  "post_type": "post",
  "permalink": "https://example.com/my-new-article/",
  "title": "My new article",
  "excerpt": "A short summary.",
  "body": "<p>The full article, as HTML.</p>",
  "categories": ["News", "Health"],
  "tags": ["research"],
  "featured_image": "https://example.com/photo.jpg",
  "meta": {
    "event_price": "GBP 49.99",
    "event_date": "2026-09-15"
  }
}

Custom post types

Everything works the same for a custom post type as for an ordinary post. Each one gets its own block on the Publishing screen, with its own address and its own choice of fields — so Products can go one place and Events somewhere else. You do not have to register anything: as soon as a post type exists on your site, it appears by itself.

Custom fields, including ACF

So it is always two separate jobs

Almost all confusion here comes from expecting Job 2 to also do Job 1. It does not.

Name, not label — the thing that catches people

In ACF you see two things side by side for every field:

Only the name works here. Find it in ACF → Field Groups → your group, in the Field Name column. Capital letters matter too — Event_Price and event_price are treated as two different fields, and normally only one of them exists.

What the Test webhook button shows you

Pressing Test webhook shows something like "price": "Example value for price" — a placeholder, not a real value from a real post. That is on purpose: the test confirms your field names are wired up correctly without needing to publish anything. To confirm real values flow, publish a real post with those fields filled in.

You do not need ACF

Worth saying plainly, because people often assume otherwise. This works with any custom field, whatever created it — WooCommerce, an events plugin, a membership plugin, your theme, or WordPress’s own built-in Custom Fields panel. ACF is simply the most popular way to create them, and does not need to be installed for this to work.

Setting it up

Custom fields are extra pieces of information you add yourself — a price, an event date, a rating. Many sites create them with Advanced Custom Fields (ACF). To include them:

1. Find the field name — not the label you see on screen. In ACF, open ACF → Field Groups, click your group, and read the Field Name column: something like event_price, not “Event Price”.
2. Tick Custom fields under Send.
3. In Custom field names, type those names, one per line.
4. Save.

• Use the field name, not the label. Capital letters matter.
• Empty fields are left out completely rather than sent blank, so check a field is present before using it.
• You do not need ACF. Any custom field works, whatever created it.

Proving the message really came from your site

This is optional. Leave the Signing secret box empty and everything still works exactly as described above.

What it solves. Your webhook address is like a secret door. If somebody else learns it — from a screenshot, a log file, a shared document — they could send fake messages that the receiving end cannot tell from yours. Signing fixes that, and also proves nothing was altered on the way.

How it works. You create one long random password, the signing secret, and give a copy to both sides. Before sending, your site mixes that secret with the exact message and produces a short fingerprint, which travels in a header called X-Hookwright-Signature. The receiving end repeats the same mixing and compares. Match means genuine and unaltered. The secret itself is never sent — only the fingerprint, which cannot be turned back into it. This is HMAC-SHA256, the same method Stripe and GitHub use.

Creating it — you do not invent it yourself. Click Generate, then Copy, then Save Changes, and paste the value into your automation platform. You never need to read or understand it. To stop signing, empty the box and save.

Two long strings, doing two different jobs

This is the mistake almost everyone makes at least once, because both are long strings of letters and numbers and look interchangeable. They are not:

The secret is copied and pasted straight across. Nothing is calculated, nothing is derived, and it never comes out of the incoming request. Whatever is shown in the Signing secret box is exactly what you paste into your automation platform.

Whatever tool you use, three things get filled in, and they mean the same thing even when the labels differ:

Once it works, move the secret out of the workflow itself and into whatever your platform uses for credentials or environment variables, so it is not sitting in plain view.

Checking it on the receiving side. Whatever you use, the three steps are the same:

1. Take the raw body of the request — the message exactly as it arrived, as text.
2. Calculate an HMAC-SHA256 of it, using your secret as the key, asking for hexadecimal output.
3. Compare sha256= followed by that result against the header. Accept only if identical.

In n8n, this exact configuration is known to work: Webhook node — Options → Raw Body on. Crypto node — Action Hmac; Binary File on with Binary Property Name data (with Raw Body enabled n8n hands the body over as binary, and this is how you reach it); Type SHA256; Property Name computedSignature; Secret: your signing secret pasted in as plain text; Encoding HEX. IF node — compare {{ 'sha256=' + $json.computedSignature }} against the header with String → is equal to. In Make, Zapier, Pipedream or your own code: find whatever the platform calls HMAC, choose SHA256 and hex, and compare. In code it is one line — crypto.createHmac('sha256', secret).update(rawBody).digest('hex') in Node.js, or hash_hmac('sha256', $rawBody, $secret) in PHP.

Keep the secret private. Anyone holding it can produce messages that look genuine. If it leaks, click Generate for a new one, save, and update the receiving side — the old secret stops being accepted immediately.

If delivery fails

It is retried twice more — after 5 minutes, then after 30 — before a notice appears in your admin area. Two cases are reported without retrying, because a retry would fail identically: a message over 1 MB, and a message that could not be prepared because of an unusual character.

What it deliberately does not do

• Password-protected posts are not sent. Their content is hidden from visitors, so it is not sent outward either.
• Only administrators can redirect a post to a different address. Other editors can still opt a post out.