What Is a Webhook? Why Some Automations Run Instantly

A webhook is an automatic message one app sends to a web address you choose the moment something happens, such as a new order or payment. Automations started by a webhook run within seconds. Others "poll", checking for new data on a timer: every 15 minutes on Zapier's free plan, every 1 to 2 minutes on paid plans.

Most of the time that delay doesn't matter. Sometimes it costs you money: an oversold item, a lead who waited, a failed payment nobody noticed until the evening. The sections below show how to tell which kind of automation you've got, when the delay is worth fixing, how to set a webhook up in Zapier or Make, and how to catch the quiet ways webhooks break.

Follow me on Instagram@sagnikteaches

Polling and webhooks, side by side

Polling is walking to the letterbox every 15 minutes to see if anything has arrived. A webhook is the doorbell: nothing happens until there's something to collect, then you know straight away. Here's the same online order handled both ways.

Connect on LinkedInSagnik Bhattacharya

10:02:00  Customer places an order

Webhook (instant trigger)
10:02:01  The shop sends the order details to your automation
10:02:04  Packing team gets a message; stock updated elsewhere

Polling (Zapier free plan, checks every 15 minutes)
10:02:00 - 10:14:59  Nothing happens; last check was at 09:59
10:15:00  Automation checks, finds the new order
10:15:03  Packing team gets a message

Zapier's help documentation lists how often polling triggers check, by plan:

Subscribe on YouTube@codingliquids

On Zapier, polling doesn't cost you tasks, because triggers aren't counted; only successful action steps are. So a polling Zap isn't more expensive, just slower. The reason the difference exists at all is on the other app's side: a webhook needs the sending app to support it, which is one of the things worth checking in a software vendor's API before you buy.

How to tell whether your automation is instant

• In Zapier, instant triggers show a lightning bolt icon in the Zap editor. No bolt means it polls.
• In Make, instant triggers carry an "instant" label. Scheduled triggers run on the schedule you set in the scenario.
• In the app's own settings, look for a "Webhooks", "Notifications" or "Developer" section where you can paste a URL. If there's one, you can usually build an instant trigger even when the ready-made connector polls.

You can't turn a polling trigger into an instant one by changing a setting. Zapier's documentation is clear that the trigger type is defined by each app's API. If the app doesn't send webhooks, your options are a faster polling plan, a different trigger app, or accepting the delay.

The icons are a clue; a stopwatch test is proof. An illustrative two-van plumbing firm has a Zap that texts the on-call engineer when the website enquiry form is submitted. To check it, submit a test enquiry and note the minute, then note when the text lands. Three tests on a Tuesday afternoon might read 14:03 to 14:15, 14:21 to 14:30 and 14:40 to 14:45: gaps of 12, 9 and 5 minutes, which is polling on a 15-minute cycle. Delays like that average about 7 and a half minutes and can reach 15. An instant trigger shows the text arriving in the same minute every time. Run the test again after any change to the plan or the trigger, because a Zap copied from a template can quietly use a polling trigger when an instant one exists.

When a few minutes' delay costs you money

Instant is not automatically better. Ask what happens in the gap.

If a delay doesn't cost anything, leave the automation polling. Every webhook is one more thing that can break, and the rest of this tutorial is largely about that.

The five parts of a webhook

1. The URL. A unique web address the receiving tool gives you. Anyone who has it can send data to it, so treat it as a secret.
2. The event. What triggers the message: "order created", "booking cancelled", "payment failed". You usually tick boxes for which events to send.
3. The payload. The data sent with the event, typically in JSON, a plain-text format of labelled fields such as order number, items and customer email.
4. The signature. A code the sender adds so the receiver can check the message genuinely came from that app. Payment and shop platforms such as Stripe and Shopify sign their webhooks.
5. The response. The receiver replies to say "got it". If it doesn't reply with a success code in time, the sender treats the delivery as failed and tries again later.

Here is what a payload might look like when an illustrative yoga studio's booking system reports a cancellation (field names vary by app; this is a made-up but typical shape):

{
  "event": "booking.cancelled",
  "sent_at": "2026-10-08T07:41:12Z",
  "booking": {
    "id": "B-30917",
    "class": "Tuesday 18:30 Vinyasa",
    "spaces_freed": 1,
    "cancelled_by": "customer"
  },
  "customer": { "id": "C-5521", "email": "member@example.com" }
}

When Zapier's Catch Hook receives this, it splits it into fields you can pick from menus, with names like Booking Class and Customer Email. The studio's automation uses just two of them: it looks up who is on the waiting list for "Tuesday 18:30 Vinyasa" and texts the first person that a space has opened. Because the booking system sends the webhook at 07:41, the waiting-list member hears within seconds, while the space is still there. The "cancelled_by" field matters too: when it says "studio" rather than "customer", the class itself is off and the automation should stay silent.

Choosing the event is where many first webhooks go wrong. Say an illustrative dental practice wants a text sent when a patient books, and ticks "appointment updated" because it looks like it covers new bookings too. It does, along with every reschedule, every note a receptionist adds and every reminder the system marks as sent. One patient receives five "thanks for booking" texts in a morning. The fix is either the narrower "appointment created" event or, if the app only offers the broad one, a filter as the first step: continue only when the payload's status field says "booked" and the created time equals the updated time. Before switching on any webhook, send three or four different test events and read what each payload says, so you know exactly which ones will reach your automation.

Setting one up in Zapier or Make

First, check whether the app already has an instant trigger in Zapier or Make (look for the bolt or the "instant" label). If it does, you don't need to handle webhooks yourself. If it doesn't, but the app lets you add a webhook URL, do this:

In Zapier

1. Create a Zap and choose Webhooks by Zapier as the trigger app. It isn't available on the Free plan; you need Professional, Team or Enterprise.
2. Pick Catch Hook, which splits the incoming data into fields you can map. Catch Raw Hook gives you the unprocessed data and headers, up to 2MB, and is only needed for unusual cases.
3. Copy the URL Zapier gives you and paste it into the sending app's webhook settings. Tick the events you want.
4. Trigger a real test event, such as a test order, and let Zapier pick it up.
5. Map the fields into your action steps, and turn the Zap on.

In Make

1. Start the scenario with a custom webhook module and copy its address into the sending app.
2. Send a test event so Make can learn the data structure.
3. Decide on ordering. By default Make processes incoming requests in parallel; switch on processing in order if sequence matters, for example stock changes. Two stock messages for the same scarf, "set to 3" at 11:00:01 and "set to 2" at 11:00:02, processed in parallel can finish in the wrong order and leave the shop showing 3 when only 2 remain.
4. Note the limits in Make's documentation: up to 300 incoming requests per 10-second window (beyond that the sender gets an error), a queue whose size depends on your plan, and execution logs kept for 3 days on standard plans.

If what comes after the webhook is an AI step, such as classifying an enquiry or drafting a reply, adding AI steps to Zapier covers that half of the build.

Worked example: the clothing shop's oversold sale

Here's an illustration. Say an online clothing shop sells through its own website and a marketplace. A Zap on the free plan updates marketplace stock after each website order, polling every 15 minutes. In a normal week that's fine.

Then it runs a 48-hour sale on a limited run of jackets, with small quantities in each size. At the peak, orders arrive every minute or two. Each 15-minute gap lets both channels sell the same last jacket. Across the sale, the shop oversells seven items. Each one costs a cancellation email, a refund, a $10 goodwill voucher and about 15 minutes of someone's time, perhaps $25 each all in, around $175 per sale, before counting the marketplace's view of cancelled orders.

The shop's platform can send a webhook for every order. Moving to Zapier Professional ($29.99 a month billed monthly, or $19.99 billed annually, for 750 tasks) and triggering the stock update from that webhook closes the gap to seconds. At about 400 orders in a normal month and 250 more in a sale month, one action per order stays under 750 tasks. Four sales a year would cost around $700 in oversells; the plan costs $240 to $360 a year. Before building anything, though, the shop should check whether its platform or marketplace offers a built-in stock sync, which might make the Zap unnecessary.

Why webhooks fail quietly, and how to catch it

Polling automations usually fail loudly: the next check errors and the platform emails you. Webhooks can fail with no sound at all, because the receiving side simply never hears anything.

• The receiver is off or broken, and the sender gives up. Senders retry, then stop. Stripe retries live-mode deliveries for up to three days with increasing gaps. Shopify retries a failed webhook up to eight times over four hours, and after repeated failures it removes the webhook subscription altogether, so it never sends again until someone recreates it. A Zap switched off for a weekend can silently delete the connection.
• The same event arrives twice. Retries can deliver duplicates. Build the automation so running it twice does no harm: for instance, check whether that order number already exists before creating a record. Developers call this being idempotent. For an illustrative personal-training business taking session payments, the difference is one extra step:
  Before: Payment received (webhook) → Create invoice in accounting software.
  After: Payment received (webhook) → Find invoice with this payment ID → Filter: continue only if none found → Create invoice, writing the payment ID into the reference field.
  Without that, a retried delivery creates a second invoice for the same $60 session, and the client gets two receipts and a reason to query the next one.
• A burst overwhelms the receiver. A flash sale or bulk import can exceed rate limits or fill a queue, and the extra messages are rejected.
• The data changes shape. A vendor renames a field and your mapping now fills in blanks. The automation "succeeds" while putting nothing useful anywhere. A realistic version: an illustrative events company's ticketing app moved the buyer's email from a top-level "email" field into a nested "buyer" section after an update. Every run still showed green in Zap history, but for eleven days new ticket buyers went into the mailing list with no email address, 64 contacts in all, and none of them got the pre-event instructions. It surfaced when the venue asked why so many guests hadn't received parking details. The fix was remapping the field, plus a filter at the start of the Zap that stops and emails the owner if the email field is empty.
• The URL leaks. Anyone with it can send fake events. Keep it out of shared documents, and where the platform signs its webhooks, have the receiving step check the signature.

Most of these show up in logs long before customers notice, if someone looks. Stopping automations breaking silently covers alerting in depth.

A ten-minute monthly webhook check

• Open the sending app's delivery log (Stripe calls it the Event deliveries tab; other apps use similar names) and look for failures in the past month.
• Confirm each webhook subscription still exists in the sending app. Removed subscriptions don't announce themselves.
• Scan Zapier's Zap history or Make's scenario history for errors and for runs with empty fields.
• Send one test event through each business-critical webhook and watch it arrive.
• Check each automation has a named owner who gets the error emails and is still at the business.

Written up, one month's check for an illustrative online tea shop fits in a few lines:

Webhook check - October
Stripe deliveries:    2 failures on the 12th (receiver timed out),
                      both succeeded on retry. No action.
Shopify subscription: "orders/create" still present. OK.
Zap history:          0 errors. 3 runs with blank "phone" -
                      expected, phone is optional at checkout.
Test event:           test order sent 09:14, packing message 09:14.
Owners:               stock sync - operations lead; payment
                      alerts - owner. Both still receive errors.
Next check:           first Monday of November

The value is in the second line. If "orders/create" had disappeared after a weekend outage, this is where the shop would find out, rather than from a customer whose order never reached the packing bench.

If you've inherited a pile of automations and don't know which ones rely on webhooks, start with an audit of the Zaps and scenarios nobody owns. And if you're choosing a platform for new builds, Zapier, Make and n8n compared covers how each handles instant triggers and pricing.

Further reads

• When Does Zapier Get Too Expensive? Finding the Tipping Point — Instant triggers can raise task counts; know the tipping point.
• Native Integrations vs Zapier: Which Should Connect Your Apps? — Sometimes a built-in sync beats building a webhook at all.
• What Connecting Two Business Apps Really Costs: Four Options — The full cost of each way to connect two apps.
• Can AI Work With the Tools Your Business Already Uses? — Webhooks are how AI steps get triggered by your existing apps.
• AI vs Rule-Based Automation: Which Does Your Task Need? — Decide whether the step after the webhook needs AI at all.
• Is It Worth Automating a Task You Only Do Once a Week? — Not every task needs instant triggers, or automation.
• Is AI Too Complicated for Non-Technical Business Owners? — Four levels of AI use, from typing into a chat box to custom builds, with honest learning times and five tests for when to bring in help.
• AI Glossary for Business Owners: 50 Terms in Plain English — Fifty AI terms in plain English, grouped by where you'll meet them, each with what it means for your decisions, plus five words vendors like to stretch.
• What Is n8n, and Should a Small Business Use It? — n8n explained for owners: how executions are counted, what the AI nodes do, cloud or self-hosting, a wholesaler's first workflow and who should skip it.
• iPaaS, Middleware or Custom Code: How Should Your Apps Connect? — iPaaS, middleware and custom code explained in plain English, with one real-shaped integration costed three ways over three years.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Zapier help documentation on how triggers work and on webhook triggers; Make help documentation on webhooks; Stripe and Shopify developer documentation on webhook retries; Zapier pricing page. Checked September 2026.