Every pattern in this course so far has used n8n as the example platform, but nothing about it is n8n-specific underneath. WordPress doesn’t know or care which automation platform is on the other end of a webhook, it’s still just HTTP. This lesson maps the same “webhooks in” and “webhooks out” patterns onto Make and Zapier, the two other platforms most teams already have somewhere in their stack.
The signed webhook pattern from Lesson 2 and the MCP session-calling pattern from Lesson 3, since this lesson assumes you understand what each step is doing and only needs to show you where the equivalent button lives on a different platform. A Make or Zapier account, whichever you’re translating to.
Step 1: The terminology translation
| Concept | n8n | Make | Zapier |
|---|---|---|---|
| The whole automation | Workflow | Scenario | Zap |
| A single step in it | Node | Module | Trigger / Action |
| Inbound webhook receiver | Webhook node | Webhooks app, Custom webhook trigger | Webhooks by Zapier, Catch Hook trigger |
| Outbound generic HTTP call | HTTP Request node | HTTP app (Make a request module) | Webhooks by Zapier, POST/PUT/GET action |
Once that table is internalized, most of what follows is “same idea, different menu.”
Step 2: Webhooks in, on Make
Make’s Webhooks app includes a Custom webhook trigger module, which works the
same way n8n’s Webhook node does: add it as the first module in a scenario, and Make
generates a unique URL. Paste that URL into your WooCommerce webhook’s Delivery URL
field, or into the wp_remote_post() call from your custom hook, exactly as you did for
n8n in Lesson 2. Signature verification works the same way too, add a module after the
webhook trigger (Make’s Tools > Set variable plus a hashing function, or a custom
JavaScript module if your plan includes it) that recomputes the HMAC and compares it
against the X-WC-Webhook-Signature or X-WP-Signature header before anything
downstream runs.
Step 3: Webhooks in, on Zapier
Zapier’s equivalent lives under the Webhooks by Zapier built-in app, using its
Catch Hook trigger. Adding it to a new Zap generates a URL the same way, and Zapier
lets you optionally extract a specific child key from the incoming JSON right in the
trigger setup, useful if you only care about part of the WooCommerce or custom payload.
Point your WooCommerce webhook or wp_remote_post() call at that URL exactly as
before. Zapier’s Catch Hook trigger doesn’t include built-in HMAC verification, so
signature checking has to happen in a Code by Zapier step (JavaScript or Python)
placed right after the trigger, using the same comparison logic from Lesson 2’s Code
node example.
Step 4: Webhooks out, calling your MCP server
For the “call WordPress” direction from Lesson 3, both platforms have a direct equivalent to n8n’s HTTP Request node:
- Make: the HTTP app’s “Make a request” module, configured with Method, URL,
Headers, and Body the same way, including a header field for
Mcp-Session-Idonce you’ve captured it from the initialize call’s response. - Zapier: Webhooks by Zapier’s POST action step, with a Headers section for
Mcp-Session-Idand a Data section for the JSON-RPC body.
The three-step MCP handshake, initialize, notifications/initialized, tools/call,
translates directly: three separate HTTP modules or action steps in sequence, each one
referencing the session ID captured from the first call’s response, the same as the
three chained HTTP Request nodes in Lesson 3. Application Password basic auth works
identically on every platform, since it’s WordPress’s REST API authentication, not
anything platform-specific.
Step 5: What doesn’t change at all
The parts that took the most care in Lessons 1 through 5, the signature verification, the CRM enrichment before notification ordering, the branch for CRM failures, the decision framework from Lesson 1, none of that is platform-specific. Rebuilding the Lesson 4 CRM-then-email chain in Make means the same three logical steps: a webhook trigger, a CRM module (Make has its own HubSpot app with equivalent Contact and Deal modules), and an Email app module. The thinking transfers completely, only the specific module names change.
Test it
Pick whichever platform your team already has a paid seat on, and rebuild Lesson 2’s webhook-in flow using the table from Step 1 as your translation guide. Fire a real test event from WordPress and confirm the payload lands in your Make scenario or Zapier Zap the same way it did in n8n’s Executions tab (Make calls this the scenario’s execution history, Zapier calls it the Zap’s task history).
Zapier’s Webhooks by Zapier action steps are solid for straightforward POST/PUT/GET calls but have less flexibility around raw request bodies and header capture than Make’s HTTP module or n8n’s HTTP Request node. If you’re driving a multi-step protocol like the MCP session handshake and it feels awkward in Zapier specifically, that’s not you doing something wrong, it’s a real platform limitation, worth knowing before you commit a complex flow to it.
Recap
Every pattern in this course, webhooks in, webhooks out, CRM chaining, Slack notifications, exists on Make and Zapier under different names but the same mechanics: Make’s Webhooks app and HTTP module, Zapier’s Webhooks by Zapier app with its Catch Hook trigger and POST/PUT/GET actions. The terminology table from Step 1 is the only new thing to learn, the actual design decisions (signature verification, ordering, error branches) carry over unchanged. The next lesson ties all of this back into the decision framework from Lesson 1.
Resources & further reading
- Make Webhooks documentation, help.make.com
- Webhooks by Zapier help, zapier.com
- n8n Webhook node documentation, docs.n8n.io