Every new order, every status change, every low-stock product is an event WooCommerce already knows about — it just doesn’t tell anyone unless you’re staring at the admin dashboard. This guide wires WooCommerce’s own webhook system into Make.com so orders log themselves, customers get updates, and you find out about stock problems before they become missed sales.
WooCommerce already tracks everything that happens in your store — every order, every status change from “pending” to “completed,” every time stock drops. The gap isn’t data; it’s that none of it leaves the WordPress admin unless someone logs in and looks. This guide closes that gap using WooCommerce’s built-in Webhooks feature (Settings → Advanced → Webhooks — no plugin required) connected to Make.com.
This is the natural counterpart to the Paystack → Make.com guide earlier in this series. Paystack tells you when money arrives; WooCommerce tells you everything about the order itself — what was bought, by whom, and what stage it’s at. Most stores benefit from both connected to the same automation system.
Order events become triggers for everything else
| Approach | How it works | Best for | Real-time? |
|---|---|---|---|
| WooCommerce Webhooks (recommended) | Built into WooCommerce (Settings → Advanced → Webhooks) — pushes a JSON payload to Make.com the instant an order event fires | Reacting to events — new orders, status changes, stock updates | ✅ Yes — instant |
| WooCommerce REST API | Make.com (or any tool) calls your store’s API using Consumer Key/Secret to fetch or update orders, products, customers on demand | Looking up extra order details, updating an order’s status FROM Make.com, scheduled reports | On-demand — not event-driven by itself |
The order.updated webhook fires on every status change — understanding what each status represents helps you decide which transitions matter for your automations.
Order created, and paste the Make.com webhook URL into the Delivery URL field. WooCommerce will generate a Secret — copy this, you’ll need it for signature verification.Order updated if you want to react to status changes (Recipe 2 below uses this). Each topic needs its own webhook entry, but they can all point to the same Make.com webhook URL, or to different scenarios if you prefer separation.X-WC-Webhook-Signature header — a base64-encoded HMAC-SHA256 hash of the request body, generated using the Secret from Step 2. Add a module (Make.com’s built-in crypto functions, or an HTTP/Tools step) that computes this hash from the raw request body and compares it to the header value. If they don’t match, filter out the request.Order updated topic, the payload includes a status field reflecting the order’s current status after the update. Add a Filter checking this field against the specific status you care about (e.g. status equals completed) so your automation only runs for the transitions that matter, not every minor update.An order.created or order.updated webhook payload is the same structure as the WooCommerce REST API order object — substantially larger than Paystack’s payload, since it includes full order details:
{
"id": 1234,
"status": "processing",
"currency": "GHS",
"total": "250.00",
"date_created": "2026-06-12T14:32:00",
"billing": {
"first_name": "Ama",
"last_name": "Owusu",
"email": "ama@example.com",
"phone": "0241234567"
},
"line_items": [
{
"name": "Kente Tote Bag",
"quantity": 2,
"total": "200.00",
"product_id": 88
}
]
}
Compared to the Paystack payload from the earlier guide, this gives you the actual order contents (line items, product names, quantities) — useful for order logs that show what was bought, not just the total amount. Note billing.phone is in local format (e.g. starting with 0) — the same reformatting step from the WhatsApp confirmations guide applies if sending WhatsApp messages from this data.
Every new order becomes a row in your order sheet — including what was actually purchased, not just the total. This extends Recipe 1 from the Paystack guide by adding product-level detail that payment payloads don’t include.
Map: id → Order ID, billing.first_name + billing.last_name → Customer, line_items (iterate if multiple) → Product/Qty columns, total → Amount, status → Status, date_created → Date.
This is the WooCommerce-side equivalent of Template 3 (Delivery Confirmation) from the WhatsApp guide — but triggered by you marking the order Completed in WooCommerce, rather than a separate manual message.
When you mark an order as Completed in WooCommerce (after the rider confirms delivery, for example), this fires automatically — closing the loop without a separate manual step in your delivery tracking process.
Orders sitting On Hold (often awaiting manual payment verification — relevant for bank transfer or Mobile Money payments not routed through an automatic gateway) can be easy to forget. This recipe ensures someone is notified the moment an order needs attention.
Particularly useful if you’re using WooCommerce’s native “Direct bank transfer” or “Cash on delivery” payment methods alongside Paystack/Flutterwave — these often default orders to On Hold pending manual confirmation, and this recipe prevents them from being silently missed.
Closes the loop from the bookkeeping category of the automation tools guide — every completed order becomes an invoice/sales record automatically, without manual re-entry.
Map line items to invoice line items, billing details to the customer record (creating a new customer in Wave/Zoho if one doesn’t exist for that email), and total to the invoice amount. Combined with Recipe 1’s order log, this gives you both an operational view (the sheet) and a financial view (the books) updating from the same trigger.
One question — a suggested sequence based on your store’s situation
—
| Issue | Likely Cause | Fix |
|---|---|---|
| Webhook shows “disabled” in WooCommerce | 5 consecutive delivery failures auto-disable a webhook | Check the webhook’s Delivery Logs (in WooCommerce → Webhooks → click the webhook) for the error response, fix the underlying issue (often the Make.com webhook URL changed or the scenario was off), then re-enable and resend. |
| order.updated fires for every tiny change, not just status | This topic fires on any order update, including ones unrelated to status (e.g. admin notes) | Always filter on the status field for the specific status you care about — don’t rely on the topic alone to mean “status changed.” |
| Phone number missing or in wrong format | Customer didn’t provide a phone number at checkout, or it’s in local format | Make the phone field required in your checkout (via WooCommerce settings or a checkout fields plugin) for stores relying on WhatsApp/SMS automation. Apply the same international-format reformatting from the WhatsApp guide. |
| Signature verification always fails | Hashing a re-serialized version of the JSON instead of the raw request body | As with Paystack, the HMAC must be computed on the exact raw bytes WooCommerce sent — not a re-parsed/re-stringified version, which can differ in whitespace or key ordering. |
| Multiple line items not handling correctly in Sheets/Telegram message | line_items is an array — directly referencing it without iterating only grabs the first item or produces an error | Use Make.com’s Iterator module on line_items if you need every product listed, or use an Array Aggregator to combine them into a single text field (e.g. “2x Kente Tote Bag, 1x Shea Butter Set”) for a single-row log entry. |
currency field into messages and logs dynamically rather than hardcoding a symbol, even if most of your orders are currently in one currency.They serve complementary purposes. Paystack’s webhook tells you the moment money arrives — useful for instant payment confirmations regardless of what’s in the order. WooCommerce’s webhook tells you about the order itself — what was bought, current status, customer details — and covers order lifecycle events (cancellations, completions) that have nothing to do with the payment moment. A mature setup often uses Paystack for “payment received, confirm to customer immediately” and WooCommerce for “here’s the full order record” and “order lifecycle status changes.” Smaller stores can start with just one — WooCommerce’s webhooks if you want full order detail and lifecycle tracking, Paystack’s if instant payment confirmation is the priority.
Yes — using the WooCommerce REST API (Consumer Key/Secret generated in WooCommerce → Settings → Advanced → REST API), Make.com can create, read, update, and delete orders, products, and customers. A common pattern: a logistics aggregator confirms delivery via its own webhook or API, and Make.com then calls the WooCommerce REST API to update that order’s status to “Completed” — which in turn fires Recipe 2 and Recipe 4 automatically, completing the automation loop in both directions.
The payment gateway plugins (covered in the WooCommerce plugins guide) handle the payment side and update the WooCommerce order status accordingly (typically to “Processing” once payment is confirmed). That status change is exactly what fires the order.updated webhook this guide uses — so the gateway plugin and this automation work together naturally: the plugin changes the status, WooCommerce’s webhook reports the change, Make.com acts on it.
WooCommerce doesn’t impose a meaningful limit on the number of webhooks for typical store sizes — you can have separate webhooks for order.created, order.updated, product.updated (useful for stock-level automations), and more, each potentially pointing to different Make.com scenarios if you prefer to keep automations separated by purpose rather than building one large scenario with many filters and branches. Either approach (one scenario with branches, or multiple focused scenarios) works — choose based on what’s easier for you to maintain and debug.
Recipe 1 (order logging with line-item detail) is the foundation — get that working first, including signature verification once you’re past initial testing. From there, Recipe 2 (completion notifications) and Recipe 4 (accounting sync) both branch off the same order.updated webhook with different status filters, so adding them is incremental once the first one is solid. Recipe 3 (on-hold alerts) is independent and can be added any time it’s useful for your payment mix.
Combined with the Paystack and WhatsApp automations from earlier in this series, this completes the operational core: payment confirmed → order logged → customer notified → status tracked through to completion → books updated — all without manual re-entry at any step.
Practical guides on automation, online business systems, and growing income from Ghana and across Africa. Visit OurInternetBusiness.com and bookmark it.