Most pages about a Zapier webhook stop at “paste the URL and you’re done”. This one covers what happens on the third Tuesday of running it: which parts of an event actually sync, which parts don’t, and the three failures that show up once a store is doing real order volume. If your Shopify Plus or subscription business is past the published $3M revenue floor, these failures cost money. Below that floor, a plain email alert does the same job.
A Zapier webhook is a URL created by the Webhooks by Zapier app. Another system sends an HTTP request to it, and Zapier starts a Zap with the contents. That is the whole mechanism, and it’s a good one. The trouble is everything the mechanism leaves to you.
What does a Zapier webhook actually sync?
A Zapier webhook syncs one thing: the body and headers of one HTTP request, handed to one Zap run. Nothing else travels with it. There is no state, no history of earlier requests, no knowledge of what the sender considers the current truth. If Shopify sends an “order created” event, the Zap sees the order as it stood when Shopify built the payload.
Those limits have practical consequences for what you can rely on.
What travels well
Small, flat, self-describing events travel well. An order ID, a customer email, a total, a status, a timestamp. Anything the receiving step can act on without asking the sender a follow-up question is a good fit. Notifications to a team channel, a row appended to a sheet, a tag applied in a customer record: these all survive because losing or repeating one is cheap.
Zapier also does the boring parsing for you. With the Catch Hook trigger, a JSON body is split into named fields you can map by name in later steps, which is why the feature is so popular with people who don’t want to write code.
What doesn’t travel at all
Four things do not come with the request, and you will assume they do.
Delivery guarantees come first. Zapier receiving your request is not the same as your action running. A Zap can be off, paused, or erroring, and the sender only knows what response it got.
Ordering is next. Nothing in the mechanism says event A is processed before event B.
Deduplication is missing too. Each request is a new run.
Sender authentication is the last gap. Anyone who learns the URL can post to it. Shopify and several other platforms sign their webhooks with a header, but checking the signature is your job. Catch Hook gives you parsed fields, and a signature check needs the exact raw body, so it’s usually a job for the Catch Raw Hook trigger plus a code step. Confirm the current options in Zapier’s documentation, because this is the sort of feature that changes.
What arrives changed
Two more things arrive in a shape you didn’t design. Nested objects are flattened into dotted field names. Arrays, such as the line items on an order, are often presented as parallel lists: one list of SKUs, one list of quantities, one list of prices. That looks fine in the field picker and goes wrong when you index into them.
The comparison table here sets what a sender can assume against what a Zapier webhook actually provides. Take from it that every row marked “you build it” is a place a production incident can start.
| Concern | What the sender may assume | What a Zapier webhook provides | Who builds the fix |
|---|---|---|---|
| Receipt | A fast success response means processed | A response once the request is accepted; the action runs afterwards | You |
| Duplicates | The receiver dedupes | Every request starts a new run | You |
| Ordering | Events are handled in the order sent | No ordering promise | You |
| Sender identity | The receiver checks the signature | Not done for you | You |
| Payload shape | The receiver follows the schema | Maps against a stored sample | You |
| Replay | Failed events can be re-sent | Failed runs can be replayed inside Zapier, but only ones Zapier received | You, for the rest |
What do you need before you build a Zapier webhook?
Three prerequisites save the most rework, and none of them is technical.
You need a written definition of one event. “Order created” sounds obvious until a subscription renewal, a draft order conversion and a manual order all create orders. Decide which of those should start this Zap, and write it down. Most webhook incidents begin with an event that nobody thought to include or exclude.
You need to know your plan. Webhooks by Zapier has been packaged differently at different times, and whether it counts against a premium or plan-limited feature depends on what you’re on today. Check the plan comparison on Zapier’s pricing page. Also work out how Zapier counts usage on your plan: Zapier bills in tasks, where a task is generally an action step that runs successfully. A Zap with a trigger and five actions consumes more than a Zap with a trigger and one, every time it fires.
You need an owner. Someone’s name goes on the alert. A webhook nobody watches fails quietly for days.
How do you set up a Zapier webhook step by step?
This setup is the one that holds up in production. It differs from the tutorial version in steps 3 to 5.
Step 1: Choose the trigger event and the payload
Pick the single event that starts the Zap. In Shopify, this means choosing the specific webhook topic rather than a broad one. If you can subscribe to “order paid” instead of “order updated”, do it. Update-type topics fire on every edit, including a fulfilment note added by a warehouse app at 2am, and each one becomes a run.
Then list the fields the Zap needs. Not the fields it might need, the fields it needs. A smaller payload has fewer places to break, and it is easier to read six months later.
Step 2: Create the Catch Hook and send a real test
In the Zap editor, choose Webhooks by Zapier as the trigger app and Catch Hook as the trigger event. Zapier gives you a unique URL. Put that URL in the sender’s webhook settings (in Shopify, a webhook subscription or the tool that creates one), then trigger a real event.
Use a real event, not a hand-typed one. Real deliveries from Shopify carry headers and fields that a curl test from your laptop doesn’t. Zapier records the first request it catches as the sample, and every mapping downstream is built against it. If that sample came from a test order with no discount code, no shipping line and one item, your mappings will look complete and behave incorrectly on the first order with two items and a discount.
Keep Catch Raw Hook in reserve. Use it when you must verify a signature, or when the sender posts a format Catch Hook won’t parse.
Step 3: Add a dedupe step before any action
Teams skip the dedupe step, and it prevents failure mode one, covered in full below. Before any step that writes, sends or charges, add a check on the event’s unique ID. Store IDs you have processed in a Zapier storage step or a table, look the new one up, and end the Zap if it’s already there.
Which ID? Use the identifier the sender guarantees to be unique per event, not per object. Shopify includes a webhook ID header on each delivery, and repeat deliveries of the same event carry the same one. An order ID alone is not enough, because an order legitimately fires several different events over its life.
Step 4: Handle errors and alert a human
Turn on Zap error notifications, and send them somewhere a person reads, not to the inbox of whoever built the Zap two years ago. Then decide what a failed action should do. For a notification, nothing. For an action that writes to a system of record, add a fallback path that logs the full payload to a sheet or table, so the event isn’t lost while someone investigates.
Name the owner in the Zap’s description. The next person to open it will thank you.
Step 5: Verify with a replay and a burst
Test the behaviours the tutorial skips. Send the same event twice and confirm one action. Send a small burst of distinct events at once, and confirm one action each with correct field values. Edit the sender’s payload (add a field, rename one on a test store) and confirm what your mappings do. Turn the Zap off, send an event, turn it on, and note exactly what happened to that event. You’re learning the failure behaviour of your particular sender, which is documented nowhere else.
What are the three things that break in a Zapier webhook?
Three failures account for most of the “Zapier lost our order” conversations. None is a bug in Zapier. Each is a gap between what the sender assumes and what the mechanism provides, and each has a fix that costs an hour, not a project.
Failure one: the same event runs the Zap twice
Senders retry. If a sender doesn’t receive a fast success response, it sends the delivery again, and a slow network or a briefly unavailable endpoint is enough to trigger that. Some platforms also send more than one event for what a human considers a single action. A paid, then fulfilled, then partially refunded order is three events, and if you subscribed loosely, all three hit the same Zap.
Zapier treats each request as new. So a Zap that emails a customer, creates a shipment or credits a loyalty account will do it twice. The damage scales with what the action does: a duplicate Slack message is noise, a duplicate store credit is a refund you have to claw back.
The fix is the dedupe step, keyed on the delivery ID. Two rules make it hold. Write the ID before the action runs, not after, so a crash midway doesn’t leave the event unrecorded. And make the action itself idempotent where the destination supports it, for example by passing an idempotency key to a payment or shipping API, so a duplicate that slips through is harmless.
Failure two: the mapped fields point at a payload that no longer exists
Zapier maps fields against the sample captured when the trigger was configured. The Zap doesn’t re-check the sender’s schema at run time. When the sender adds a field, that’s harmless. When it renames one, moves it inside an object, or changes a value from a number to a string, your mapping keeps pointing at the old location and passes an empty value downstream.
The nasty version is the array problem. Line items arrive as parallel lists, and a step that takes “the first SKU” and “the first quantity” works perfectly on single-item orders. On an order with three lines, a step that isn’t looping can pair the wrong values or collapse them into a single comma-separated string. A test order with one item never shows you this. It shows up on the day of your largest order.
There are three fixes, and you want all of them. Test with a deliberately awkward sample: multiple line items, a discount code, a missing optional field. Add a guard step that stops the Zap and alerts a human when a required field is empty, so a silent blank becomes a loud failure. And when the sender announces a version change, refresh the sample in the trigger and re-check every mapping, not only the ones you expect to be affected.
Some senders let you pin the API version of a webhook. Do it. A pinned version means the payload shape changes when you choose, not when the vendor does.
Failure three: the Zap goes quiet and the sender gives up
A Zap that is turned off, over its plan’s limit or stuck in an error state doesn’t always reject requests loudly. From the sender’s side, what matters is the response it gets. Repeated failures make many platforms retry for a while and then stop, and some remove or disable the subscription entirely. Shopify’s documentation describes removing a subscription after sustained delivery failures. Read your sender’s equivalent policy.
The result is the worst kind of outage: the Zap looks fine when you open it, the history shows a clean run of successes up to the outage, and nothing marks the point where events stopped arriving. There is nothing in the Zap to replay because Zapier never received the events.
The fix has two parts. First, a heartbeat: a scheduled check that compares a count from the source system, orders created in the last hour for example, with the number of runs the Zap received, and alerts on a mismatch. Second, a reconciliation path: a way to pull the missed events from the source system’s API and feed them through the same dedupe step. Because you built the dedupe step in Step 3, re-feeding events is safe.
Do this before you need it. Building reconciliation after an outage means doing it while someone is asking where their orders went.
How does a Zapier webhook compare with polling triggers?
A Zapier webhook is push: the sender decides when to call. A polling trigger is pull: Zapier asks the source on a schedule and picks up whatever is new since the last check. Each has a failure profile, and picking by the failure you can tolerate is better than picking by which is faster.
| Webhook (push) | Polling trigger (pull) | |
|---|---|---|
| Speed | Starts as soon as the sender calls | Waits for the next poll |
| Missed events | Lost if Zapier isn’t accepting requests | Usually caught on the next poll, since Zapier asks for what’s new |
| Duplicates | Possible from sender retries | Possible if the source’s “new” marker is unreliable |
| Setup effort | You configure the sender | Zapier’s app connection handles it |
| Best for | Time-sensitive, low-cost-of-repeat actions | Actions where a late run is fine and a lost one isn’t |
Take from the table that polling trades speed for recovery. If a lost event costs you money and a five-minute delay doesn’t, polling can be the more dependable design, even though it feels less modern.
What does a Zapier webhook cost at volume?
The cost of a Zapier webhook is set by the plan’s billing unit and by how many steps run after the trigger, not by the webhook itself. Zapier bills in tasks, and each successful action step in a run generally counts. A webhook that starts a nine-step Zap uses far more of your allowance per event than one that starts a two-step Zap, so a store that fires the same Zap on every order sees the bill move with order volume times steps.
That’s why the dedupe and filter steps matter twice. They stop the wrong actions, and they stop the spend. Filter steps that end a Zap early generally don’t count as tasks, though you should confirm how your plan counts them in Zapier’s help documentation.
Compare this with a workflow tool that bills by execution, where a run of the whole workflow counts once regardless of how many nodes it passes through. For a long, branching flow at high volume the two models can price very differently, and you should read both vendors’ current pricing documentation before deciding. The n8n side of that trade is covered in n8n versus Zapier, and the wider platform choice in Make.com versus Zapier. To work out your own number, take a month of events for the trigger, multiply by the successful action steps per run, and compare it with your plan’s allowance. The result is a figure to confirm against your account, not one to estimate from a blog post.
When should you not use a Zapier webhook?
Skip it when a duplicate or a lost event is expensive and can’t be reconciled later. Money movement, inventory decrements and anything that triggers a physical shipment are the obvious cases. There, an event queue, or a job that reads the source system with a cursor, gives you replay and ordering that a Zapier webhook doesn’t.
Skip it when you can’t verify the sender and the action is consequential. An unauthenticated URL that can issue store credit is an open door. If you can’t check the signature, keep the Zap limited to actions that a forged request can’t hurt.
Skip it when the flow involves a decision that carries risk on unreliable data. Refunds approved without a human, for example, don’t belong in a chain where a mapped field can silently be empty. If a wrong answer costs more than a person’s minute, put a person in the loop.
And skip it when the logic is long. A Zap that grows past a screen of steps is a program without version control, tests or code review. At that point a self-hosted workflow engine such as the one in self-hosted n8n or an agent-style build like n8n AI agents gives you the control you’re starting to need, and the broader picture is in AI workflow automation.
Who is a Zapier webhook not for?
It’s not for a brand under the published $3M revenue floor that only wants a Slack ping on each order. That brand should use the notification built into the platform and avoid the maintenance. It’s also not for a team with nobody to own the alerts: a webhook without an owner is a future incident with a delay on it.
It suits an operations lead at a Shopify Plus brand who needs a fast, low-risk bridge between two systems, accepts that the bridge has no guarantees, and has built the three guards. For that person a Zapier webhook is often the right answer for the first version of a flow, and the honest opinion is that most flows should stay there for a while. The mistake isn’t using it. The mistake is treating a URL that accepts requests as a system that keeps promises.
What should you do about a Zapier webhook that has outgrown its Zap?
Recognise the signs. You’ve added a second dedupe table. There’s a code step nobody wants to touch. Reconciliation is a monthly spreadsheet exercise. Someone has said “don’t change that Zap” out loud. These mean the flow has stopped being a convenience and started being infrastructure, and infrastructure needs an owner, a test and a design.
The design question is the same every time: what is the source of truth, what happens when an event is duplicated, late or lost, and who is told. That’s an AI agents and automation problem, not a Zapier problem, and it’s the work Pointerflow’s AI agents service does: designing the workflow, its guards and its reconciliation so a webhook becomes one reliable part of a system rather than the whole of it.
Sources
- No external figures are quoted. The article is written from how webhook delivery, retries and Zapier’s task-based billing generally work, and points the reader to Zapier’s and the sender’s own documentation for current limits and plan details.