Sending webhooks from WordPress to Zapier, Make, n8n and Slack

#What a webhook is, in one paragraph

A webhook is WordPress making an HTTP POST to a URL you choose when something happens: a post is published, a user registers, a comment lands. The receiving service (Zapier, Make, n8n, Slack, a CRM, your own code) reads the JSON body and does something with it. It is the simplest way to get events out of WordPress without polling, and every automation platform speaks it.

#Step 1: get a destination URL

• Zapier: create a Zap with the "Webhooks by Zapier" trigger, choose Catch Hook, copy the URL.
• Make: add a Webhooks module, Custom webhook, copy the address.
• n8n: add a Webhook node, set it to POST, copy the test or production URL.
• Slack: create an incoming webhook for a channel in your Slack app settings. Slack expects a specific body shape ({"text": "..."}), so for Slack you will usually go via Zapier, Make or n8n rather than posting the raw event.
• Your own endpoint: any HTTPS URL that accepts POST.

It must be HTTPS. The plugin will not post events to a plain HTTP address.

#Step 2: create the webhook

Install Dragon Webhook Manager, open Tools, then Webhook Manager, then Add New, pick a trigger, paste the URL, save. Triggers cover the events people actually automate on: post published or updated, page changes, user registered or updated, comment posted, and more. There is no cap on how many webhooks you create.

#Step 3: understand the payload

The body is JSON containing the event's object: the post (id, title, slug, status, URL, author, dates, taxonomies), the user (id, login, email, roles), or the comment. The edit screen shows a field reference per trigger, so you can map fields on the receiving side without guessing. Sensitive fields are not included; a user event carries the account, not its password hash.

Trigger the event (publish a test post) and look at the receiving platform: Zapier and Make show the caught sample, which you then map into the next step.

#Step 4: read the delivery log

The Logs tab records every delivery with the response code, the time it took and the payload sent. This is where integrations get debugged:

A failed delivery can be retried in one click from the log.

Under Settings, set how many days of logs to keep and how long to wait for an endpoint before a delivery counts as failed.

#Step 5: make it trustworthy

Two problems appear once a webhook matters:

The receiver cannot tell it is really you. Anyone who learns the URL can POST fake events. Dragon Webhook Manager Pro signs every delivery with HMAC-SHA256 using a secret from its settings screen; your endpoint recomputes the signature over the body and rejects anything that does not match. Zapier and Make can check it in a filter step; your own code should always check it.

The receiver was down for a minute. Without retries, that event is lost. Pro retries failed deliveries with backoff, and the log shows every attempt.

Pro also adds conditional firing rules, so a webhook fires only when the event matches (a post in one category, a user with one role), and more than twenty WooCommerce triggers for orders, customers and stock. Store automations are covered in WooCommerce order webhooks.

#Common automations that take ten minutes

• New post published: post to a Slack channel, schedule social posts, notify a newsletter tool.
• New user registered: add to a CRM or mailing list, open a welcome ticket.
• Comment posted: alert the moderators, run it through a spam or sentiment check.
• Post updated: rebuild a static front end, purge a CDN cache.

#Checklist

• Destination URL is HTTPS and copied in full
• Test event delivered with a 2xx in the log
• Payload fields mapped on the receiving side
• Log retention and timeout set
• Signature verified on the receiver (Pro)
• Retries on for anything that matters (Pro)