Why not WooCommerce's built-in webhooks?
WooCommerce ships a webhook feature, and for a single simple integration it works. Teams outgrow it in three places: there is no conditional logic (every order fires every webhook, and the filtering has to happen on the other side), the delivery log is thin when something goes wrong, and failed deliveries are retried only in limited ways. When an order webhook is how the warehouse learns it has something to ship, "we think it sent" is not good enough.
Dragon Webhook Manager Pro adds more than twenty WooCommerce triggers to the free Webhook Manager, plus conditional firing rules, HMAC-SHA256 signing and automatic retry with backoff. The basics of creating a webhook and reading the log are in sending webhooks from WordPress; this guide is the store-specific part.
The triggers you will use
- Order created: the moment checkout completes. The starting point for CRM, fulfilment and notification flows.
- Order status changed, with the new status in the payload: processing means paid, completed means shipped, cancelled and refunded need their own handling, and on-hold is usually a payment awaiting confirmation.
- Product created, updated, deleted: sync a catalogue to a marketplace, a price comparison feed or a PIM.
- Stock changed and low-stock: reorder alerts, warehouse sync, hide out-of-stock items from ads.
- Customer created or updated: CRM and mailing list.
Design one webhook per job
Resist the single "everything" webhook. A warehouse wants paid orders and nothing else; the accountant wants completed and refunded; Slack wants a one-line summary of new orders above a certain value. Create a webhook per consumer and use conditional rules so each fires only on the events it cares about: status equals processing, total above 100, a product in a given category. Filtering at the source means the receiving automations stay simple and your delivery log reads cleanly.
Sign everything
An order webhook URL that leaks lets anyone inject fake orders into your fulfilment system. Set the signing secret on the Pro settings screen; every delivery then carries an HMAC-SHA256 signature computed over the exact body. On the receiving side:
- Read the signature header and the raw request body.
- Compute HMAC-SHA256 of the body with the shared secret.
- Compare with a constant-time comparison. Reject on mismatch.
Zapier and Make can do this in a code or filter step; n8n has a crypto node; your own endpoint should do it before parsing anything.
Retries and idempotency
With retries on, a delivery that fails (5xx, timeout, connection refused) is retried with backoff and every attempt appears in the log. That solves the receiver's downtime, and it introduces the one thing your receiver must handle: the same event may arrive twice. Use the order id (and status) as an idempotency key and make the receiving action safe to repeat. "Create shipment for order 1234 if none exists" is correct; "create a shipment" is a duplicate waiting to happen.
Testing without real orders
Place a test order with a test payment gateway (or a 100% coupon), watch the delivery land in the log with a 2xx, check the payload fields on the receiver, then change the order status by hand and watch the status-change webhook follow. Refund it and confirm the refund event reaches the systems that need it. Only then point the webhooks at production URLs.
Payload hygiene
Order payloads contain personal data: names, addresses, emails. Send only to systems that need them, over HTTPS, and set a log retention in the free plugin's settings that matches your privacy policy, because the delivery log stores the payload too.
Checklist
- One webhook per consumer, each with a conditional rule
- Signing secret set, signature verified on every receiver
- Retries on; receivers idempotent on order id
- Test order, status change and refund all seen in the log and downstream
- Log retention set to match your privacy policy