Make.com Webhook Tutorial: How to Receive, Parse, and Act on Any Webhook in Minutes

Webhooks are the backbone of most real automation work. They are how apps tell other apps that something just happened — a form was submitted, a payment completed, a call ended, a record was updated. Learning to receive and handle webhooks in Make.com unlocks a huge range of integrations that have no native connector, and it makes the ones that do have connectors significantly more flexible.

This Make.com webhook tutorial covers everything from receiving your first payload to parsing complex nested data and triggering downstream actions based on what came in. If you're brand new to Make.com itself, start with Make.com Tutorial for Beginners first.

What a Webhook Actually Is

A webhook is an HTTP POST request. When something happens in an external system, that system sends a POST request to a URL you specify, with data about the event in the request body. The receiving end processes that data and acts on it.

Unlike polling — where you check an API every few minutes to see if anything changed — webhooks are event-driven. The notification comes to you the moment the event happens. This makes webhook-driven automations faster and more reliable than scheduled polling.

In Make.com, the Webhooks module is your receiving end. Make gives you a unique URL. You paste that URL into the sending system as the webhook destination. When the event fires, Make receives the data and your scenario runs.

Setting Up Your First Webhook Trigger

Open Make.com and create a new scenario. Click the trigger module slot and search for Webhooks. You will see two options: Custom webhook and Custom mailhook. Choose Custom webhook for HTTP-based payloads.

Create a new webhook and give it a name that identifies the integration — something like Retell Call Ended or Typeform Submission. Make generates a unique HTTPS URL. Copy it.

Now paste this URL into the sending system as the webhook endpoint. Where exactly depends on the system:

• In Retell AI: Settings > Webhooks > Add endpoint
• In Typeform: Connect > Webhooks > Add a webhook
• In GoHighLevel: Automation > Webhook action, or Settings > Integrations
• In a custom application: wherever you configure outgoing HTTP calls

Back in Make, the webhook module now shows Waiting for data. Submit a real event in the sending system. Make receives it and shows you the captured data structure. This is important: Make needs a sample payload before you can map fields in subsequent modules. Always send a real test event before building out the rest of the scenario.

Understanding the Data Structure

Webhook payloads are almost always JSON. When Make receives the payload, it parses the JSON and makes every field available for mapping in downstream modules.

A simple payload might look like this:

{
  "event": "call_ended",
  "call_id": "abc123",
  "caller_name": "Sarah Johnson",
  "caller_phone": "+14085551234",
  "duration_seconds": 187,
  "transcript": "Hello, I am calling to schedule..."
}

After Make receives this, you can reference any of these fields in downstream modules: {{1.caller_name}}, {{1.caller_phone}}, {{1.duration_seconds}}, and so on. The number refers to the module number, and the key name matches the JSON field.

Nested objects work the same way. If your payload has:

{
  "contact": {
    "email": "sarah@example.com",
    "tags": ["new-lead", "webinar"]
  }
}

You access the email as {{1.contact.email}} and the tags array as {{1.contact.tags}}.

Parsing Arrays: The Iterator Module

Arrays are where many beginners get stuck. If your webhook payload contains an array — a list of items — and you want to process each item separately, you need the Iterator module.

Add an Iterator module after the webhook. Set the Array field to the array in your payload. The Iterator outputs one item at a time, and all subsequent modules run once per item. This is how you process multiple results, multiple tags, multiple line items, or multiple records from a single webhook payload.

For example, if a webhook delivers an array of ten new contacts, the Iterator processes each one in turn, and your CRM module creates ten individual contact records.

Filtering Webhooks: Only Act on What You Need

Many systems send webhooks for multiple event types to the same URL. Retell AI sends call_started, call_ended, and call_failed events to the same webhook endpoint. You usually only want to act on one of them.

Handle this with a Filter between the webhook module and the next action. Right-click the connector line and select Set up a filter. Set the condition: only continue if {{1.event}} equals call_ended. Events that do not match that condition are received by Make but stop at the filter without triggering any downstream actions.

Alternatively, use a Router to handle multiple event types in the same scenario: one branch for call_ended with its own action sequence, another branch for call_failed with a different response.

A Real Example: Retell AI Call to GoHighLevel CRM

Here is a complete webhook scenario I build regularly for voice agent clients — the same pattern behind AI Voice Agent for Small Business.

Trigger: Retell AI webhook fires when a call ends. Payload includes caller phone number, call duration, transcript, and any data the agent extracted during the conversation (caller name, reason for call, appointment preference).

Filter: Only continue if event type is call_ended and duration is greater than 30 seconds. Calls under 30 seconds are usually hang-ups, not real leads.

Search GoHighLevel contacts: HTTP module calls the GHL API to search for an existing contact by phone number. Returns the contact ID if found, null if not.

Router: Branch 1 if contact exists (update it), Branch 2 if contact does not exist (create it).

Create or update contact: HTTP module to GHL API with contact fields mapped from the Retell webhook payload. Tags applied based on call outcome.

Send confirmation SMS: GHL SMS action to the caller confirming their appointment or follow-up, using the caller name and booked time extracted from the transcript.

Slack notification: Post a summary to the team channel with caller name, phone, and reason for call.

That is six modules. It runs in under two seconds from call end to CRM update and SMS send. The API Request Tester is useful for verifying GHL API calls and headers before wiring them into the Make scenario.

Handling Webhook Errors and Retries

Make.com expects your webhook scenario to process the incoming payload without errors. When a downstream module fails — the CRM API returns an error, a required field is missing — Make logs the failed execution and can notify you by email.

For scenarios handling important data, add error handling explicitly. Use the Ignore error handler on non-critical modules so a single failure does not stop the entire execution. Use the Break handler for critical modules where you want the scenario to pause and alert you if something goes wrong. Make.com Error Handling covers this in more depth.

For webhook endpoints that receive high volume, enable the scenario queue in Make.com settings. This allows Make to queue incoming webhooks and process them in order rather than dropping payloads if the previous execution has not finished.

When you are mapping data between JSON payloads and Make modules, the JSON Formatter helps you visualise nested structures before you build the mapping logic.

Securing Your Webhook Endpoint

Make.com webhook URLs are unique and long, which provides basic security through obscurity. For higher-security applications, Make supports two additional options.

IP filtering: Restrict the webhook to only accept requests from specific IP addresses. Use this when the sending system has fixed outbound IPs.

Custom headers: Require a specific header value in the incoming request. Set a secret token in the sending system and validate it in Make with a filter that checks the header value before processing. This is the same signature-verification principle covered in Python FastAPI Webhook Automation for backends that receive webhooks directly instead of through Make.

For production integrations handling sensitive data, implement at least one of these in addition to using HTTPS (which Make webhooks do by default).

What to Build Next

Once webhook handling is solid, the natural next step is learning to send webhooks out from Make — calling external systems as part of your scenario using the HTTP module. Combined with incoming webhooks, this lets you build fully bidirectional integrations between any two systems that support HTTP, regardless of whether Make has a native connector for either. Make.com HTTP Module Tutorial covers exactly that.

For planning complex webhook-driven scenarios before building them, the Workflow Visualizer helps map the full data flow across modules before you start wiring things together in Make.

Webhook integrations like the Retell-to-GHL example above are the backbone of most voice agent and CRM projects I build for clients. If you want help building a specific webhook integration or are hitting a technical wall in a scenario, book a free 30-minute call. Bring the payload structure and the target action and we will get it working.