October 6, 2026

Make.com Webhooks for Beginners: A Plain-English Tutorial (With a Real Example)

The one-paragraph version

A webhook is just a URL that listens. When something happens in another app, that app knocks on the URL and hands Make some data — instantly, no polling, no waiting. If you've ever wished Make would react the moment something happens instead of checking every 15 minutes, you need a webhook. Below: what they are in plain English, when to use one, and a complete working example (a contact form that creates a CRM row in real time) in about 20 minutes.

What a webhook actually is (no jargon)

Forget the technical definitions. Here's the mental model:

Polling (the normal Make trigger): like calling a restaurant every 15 minutes to ask "is my table ready?" It works, but it's slow and a little rude.

Webhook: like giving the restaurant your phone number. They call you the instant the table is ready.

Technically: a webhook is a unique URL that Make generates for you. You give that URL to another app (a form builder, a payment processor, your website). When an event happens there, that app sends the event data to your URL via HTTP POST, and your Make scenario runs immediately with that data.

Three properties that matter:

1. Instant. No 15-minute polling interval (which is also Make's free-plan minimum, so webhooks are the only way to get real-time behavior for free).
2. Push, not pull. The other app sends data to you; Make doesn't go looking for it.
3. One URL per webhook. Each "Custom webhook" module in Make generates its own address. Lose it and you just generate a new one.

When you actually need a webhook

You need one when timing matters or no normal trigger exists:

• A contact form submission should create a CRM lead now, not within 15 minutes.
• A payment success should trigger a welcome email now.
• An app you use has no Make integration at all, but it can "send a webhook" (many can — it's often buried in settings under "Notifications" or "API").
• You want to connect two systems and one of them only speaks webhook.

You don't need one for: daily reports, nightly syncs, anything where "within 15 minutes" is fine. Scheduled triggers are simpler — use them when you can.

The example: contact form → CRM row, in real time

We'll build: visitor submits a contact form → Make receives it instantly via webhook → creates a row in Google Sheets (your stand-in CRM) → sends you a Slack notification. Four modules, ~20 minutes.

Step 1: Create the webhook in Make (3 minutes). New scenario → add module → search "Webhooks" → choose "Custom webhook" → "Add" → give it a name like "Contact form" → Save. Make shows you a URL like https://hook.make.com/abc123.... Copy it. That URL is now listening.

Step 2: Point your form at it (5 minutes). I'm using Tally (free) for this example, but any form tool with a webhook/notification URL field works — Typeform, Jotform, even a WordPress form plugin.

• In Tally: form settings → Integrations → Webhooks → paste the Make URL.
• Submit a test entry with obviously fake data ("Testy McTestface", test@example.com). In Make, right-click the webhook module → "Run this module only" first, then submit the form. Order matters: the module must be listening when the data arrives.

Step 3: Read the data structure (2 minutes). After the test submission, click the webhook module's output bubble. You'll see the form fields as a bundle: name, email, message, timestamp, maybe some metadata. This is the raw material for everything downstream. If a field is missing, your form didn't send it — fix the form, not Make.

Step 4: Add the Google Sheets module (5 minutes). Add module → Google Sheets → "Add a row". Connect your account, pick the spreadsheet, map the webhook's name → Name column, email → Email column, and so on. Mapping is drag-and-drop from the webhook's output bundle.

Step 5: Add the Slack notification (3 minutes). Add module → Slack → "Send a message". Channel: your #leads channel (or DM yourself). Message: "New lead: [name] ([email]) — [message]".

Step 6: Turn it on. Toggle the scenario ON. The webhook URL stays live as long as the scenario is on. Submit one more real test through the actual form (not Make's test runner) to confirm the whole chain works end to end.

That's it. Form submitted → row created + Slack ping, typically within seconds.

The three errors everyone hits

1. "I submitted the form but nothing happened." Nine times out of ten: the scenario wasn't listening. Either you forgot to run the module once to "learn" the data structure, or the scenario is off. Webhooks only fire into a scenario that's on (or a module that's in listening mode during setup).

2. "It worked in testing but stopped." Check whether you regenerated the webhook URL. Each Custom webhook module has one URL; if you deleted and re-added the module, the old URL is dead and your form is shouting into the void. Re-paste the new URL into the form settings.

3. "The data looks weird — nested bundles." Some apps send webhooks with nested JSON (an object inside an object). In Make, click through the bundle tree to find your field — it's there, just one level deeper than expected. If you need the same nested value in many places, use a "Set variable" module once and reference the variable.

A note on security (short, because it matters)

A webhook URL is a capability: anyone who has it can trigger your scenario. Don't post it publicly, don't commit it to a public GitHub repo. For anything beyond a contact form — payments, user data — check whether the sending app supports webhook signatures or secret tokens (Stripe does; most form tools don't bother, which is fine for a contact form). Make's paid plans offer more control here, but for typical small-business use, "keep the URL private" is the whole security policy.

Webhooks vs. Make's normal triggers: a cheat sheet

Three more webhook recipes (steal these)

Once the contact-form pattern clicks, these are the next three I built — same shape, different apps:

1. Payment → welcome sequence. Stripe can send a webhook on checkout.session.completed. Make receives it → creates/updates the customer row → sends the welcome email with login details → notifies you in Slack. This replaced a manual "check Stripe every morning" routine. Note: Stripe webhooks support signing secrets — turn that on in the Stripe dashboard and validate it in Make. For money events, "keep the URL private" isn't enough.

2. Booking → prep doc. Calendly (or Cal.com) sends a webhook on new bookings. Make receives it → creates a meeting prep doc from a template (agenda, attendee LinkedIn, last-contact summary) → drops it in your Notion meetings database. I walk into sales calls with a one-page brief I didn't write. It feels like cheating.

3. Form → segmented follow-up. Same contact form, but add a Router after the webhook: if the "interest" field says "enterprise," create a CRM deal and ping the sales channel; if "freelancer," send the self-serve onboarding email. Routers are free in Make, and this turns one dumb form into a triage system.

Debugging with execution history (your new best friend)

When a webhook scenario misbehaves, don't guess — inspect. Make keeps an execution history for every run: click the scenario's history tab, open the failed run, and click each module to see exactly what data went in and what came out.

The pattern I teach: follow the bundle. Every module receives a bundle (input) and produces a bundle (output). When something breaks, find the first module where the output isn't what you expected — that's your bug, and it's almost always a mapping issue (wrong field dragged in) or a data-shape issue (the app sent an array where you expected a single value).

Two practical habits:

• Re-run with the same data. Make lets you re-run a failed execution after fixing the mapping. You don't need to re-submit the form — the original webhook payload is preserved. This turns debugging from a 10-minute cycle into a 1-minute cycle.
• Add a "log to Sheets" module while building. A temporary Google Sheets module that dumps the raw webhook bundle into a row. Ugly, invaluable. Delete it when the scenario is stable. I still do this on every new webhook integration — the 2 minutes it costs has saved me hours of squinting at bundle trees.

What this costs

• The tutorial: $0. Make's free plan (1,000 credits/month) includes custom webhooks. This scenario burns ~3 credits per form submission — 300 submissions a month and you're still free.
• The form: $0 (Tally free, or whatever form tool you already use).
• If you outgrow free: Make Core at $9/month (10,000 credits). Webhooks don't cost extra on any plan.
• What I'd skip: paying for a "webhook management" tool at this scale. Make's built-in webhook module plus the form tool's native webhook setting is everything you need until you're handling thousands of events a day.

Pricing checked October 2026. Make's free-plan limits (1,000 credits, 2 active scenarios, 15-minute polling minimum) are the reason webhooks matter so much on free — they're your only real-time option without paying.

← Back to all field notes