Connecting Magento 2 to Zapier, Make, or n8n

Zapier, Make, and n8n all accept incoming webhooks: each gives you a URL, and anything that can POST JSON to that URL can trigger a workflow. Magento 2 cannot do that POST out of the box, which is the gap the OCM Labs Webhooks module for Magento 2 fills; we build and sell it, so factor that in. This post shows how the two halves meet: the module sends a JSON payload you shape yourself, the platform catches it and runs your Zap, scenario, or workflow.

One honest note before the how-to. We are not claiming a certified Zapier app or a Make marketplace listing, and the module docs do not ship canned recipes for these platforms. What the module gives you is the universal interface all three consume: an HTTP POST with a body you control, sent to any URL you paste in. That is the whole trick, and it is enough.

Why a webhook instead of a Magento connector app?

Because the connector apps for a self-hosted Magento mostly poll the REST API, and polling means delay, API load, and one more credential with broad store access. A webhook inverts it: your store pushes one small request per real event, seconds after it happens, to a URL that does exactly one thing. For the fuller push-versus-poll argument, see the complete Magento 2 webhooks guide.

There is also a control argument. A connector decides what an "order" payload looks like. With your own webhook you decide, which matters more than it sounds, as we will get to under payload shaping.

How does each platform receive a webhook?

All three work the same way at the core: create a webhook trigger, get a unique URL, paste that URL into the destination field of a webhook in System > OCM Labs > Webhooks, and send a test.

Zapier. The trigger app is Webhooks by Zapier with the Catch Hook event. Zapier gives you a unique URL, parses the JSON body of whatever you POST to it, and splits each field out for mapping into later Zap steps. A Catch Raw Hook variant returns the unparsed body plus headers if you need them. One planning note: Webhooks by Zapier is not on Zapier's free plan; it requires one of the paid tiers.

Make. The Custom webhook module generates a unique URL that triggers your scenario the moment data arrives. Make determines the payload's data structure from a sample request you send to the URL, after which every field is mappable in downstream modules; you can also predefine a data structure if you want incoming payloads validated.

n8n. The Webhook trigger node gives you two URLs, test and production. The test URL shows incoming data live in the editor while you build; the production URL takes over once the workflow is active. n8n also supports authentication on the webhook itself (Basic, Header, or JWT auth) plus an IP allowlist, and you can self-host it, which matters if order data is not allowed to transit a third-party automation cloud.

What does payload shaping mean for no-code tools?

It means sending the JSON the mapper wants to see instead of whatever your platform felt like serializing. No-code field mappers are happiest with a small, flat, predictably named payload. A raw Magento order object dumped to JSON is dozens of nested keys, most of them noise to a Zap that needs five values.

The module's Smarty payload templates let you build exactly the payload the workflow consumes. For an order-placed hook feeding a no-code tool, we send something like:

{
  "order_id": "{$order.increment_id}",
  "customer_email": "{$order.customer_email|escape_json}",
  "grand_total": {$order.grand_total|number_format:2:".":""},
  "currency": "{$order.order_currency_code}",
  "item_count": {$order.items|count},
  "placed_at": "{$meta.triggered_at}"
}

Six flat fields, named for humans. In Zapier that becomes six clean mapping tokens. In Make it becomes six recognized fields after one sample. Nobody downstream ever writes a "get the third element of items and dig out sku" expression.

The test flow fits together well here. Make and Zapier both learn the payload structure from a sample request, and the module's Send Test button delivers one synchronously, rendered from real store data, before you have even saved the webhook. So the loop is: create the trigger on the platform, copy the URL into the module, click Send Test, watch the platform recognize the fields, then map them. Test deliveries carry an X-Webhook-Test: 1 header and "test": true metadata if you template it in, so you can filter them out of a live workflow.

Worked example: order placed to Slack and a spreadsheet

Here is the shape of the first automation most stores build, using Zapier as the example (Make and n8n are the same steps with different nouns):

1. In Zapier, create a Zap with Webhooks by Zapier, Catch Hook as the trigger. Copy the URL.
2. In Magento, go to System > OCM Labs > Webhooks, open the disabled Order Placed sample webhook that ships with the module, and paste the Zapier URL as the destination.
3. Trim the payload template to the fields the Zap needs, like the six-field example above.
4. Click Send Test. Zapier catches the sample and shows the parsed fields.
5. In the Zap, add a Slack step (post a message to #orders with the order ID and total) and a Google Sheets step (append a row with all six fields). Map the caught fields into each.
6. Save and enable the webhook in Magento, turn the Zap on, and place a test order.

From then on, every order posts to Slack and lands in the sheet within seconds of placement, and the module's delivery log shows every attempt with the HTTP status Zapier returned. Multi-store note: webhooks can be scoped to specific store views, so a Zap can serve one brand without hearing about the others.

How do you keep the connection secure?

Three layers, in increasing order of effort:

• The URL itself. All three platforms issue long, unguessable webhook URLs. Treat the URL like a credential and that is real, if modest, protection.
• A shared header. The module supports custom headers per webhook. Set a header like X-Store-Token to a secret value, then have the workflow check it: n8n's Header auth does this natively, and on Zapier or Make a first filter step can compare the field. Cheap and effective.
• HMAC signatures. Every delivery from a webhook with a secret configured carries an X-Webhook-Signature HMAC-SHA256 header computed over the raw body. Verifying it needs code that can access raw bodies and compute an HMAC, which is natural in n8n or any endpoint you own, and clumsy in pure no-code steps. If you need signature verification but want to keep the no-code target, put a small verifying relay you control between store and platform.

Also remember the module side has a moving part: deliveries only happen while the queue consumer is running, so check installation and the queue consumer if webhooks save fine but nothing arrives.

Which platform should a Magento store pick?

Whichever one your team already lives in, honestly. Beyond that: Zapier has the widest app catalog and the least friction for business users, but webhooks require a paid plan. Make prices generously per operation and handles branching scenarios well. n8n is the developer's pick: self-hostable, real code steps when you need them, and native webhook authentication. The module does not care; it is the same POST to all three.

The OCM Labs Webhooks module is $250 for Magento Open Source and Adobe Commerce 2.4.7 to 2.4.8. If you are comparing it against building the pipeline yourself or against Adobe's eventing stack, read webhooks vs Adobe I/O Events vs custom observers, and our Magento extensions page covers the rest of the catalog.