Make.com Webhook Automation Examples

A practical field guide from Automation Ace.

Real Make.com Webhook Automation Examples

Webhooks in Make.com unlock integrations that no pre-built connector can replicate. If you are new to webhooks, start with what is a webhook for the fundamentals, or APIs vs. webhooks explained for how these two communication patterns differ. — any system that can send an HTTP POST can now trigger a Make scenario and feed its data into your workflow. Understanding how to receive, validate, parse, and act on webhook payloads is the skill that separates basic Make users from people who can connect anything to anything.

The examples below come from real scenarios I have built for clients. Each one illustrates a different aspect of webhook-driven automation: payload parsing, conditional routing, iterating over arrays, and sending responses back to the triggering system.

Example 1: Stripe Payment → Airtable Invoice Record + Slack Alert

A Stripe webhook fires every time a payment succeeds. The payload includes the customer ID, amount, currency, payment method, description, and metadata object. In Make, a Custom Webhook module receives the POST. A Set Variable module extracts the nested values: data.object.amount (in cents, divide by 100), data.object.customer, data.object.metadata.project_id (a custom field set when creating the Stripe payment intent).

An HTTP module then calls the Stripe API to retrieve the full customer object using the customer ID, pulling the customer's email and name. An Airtable Create Record module writes: Client Name (from customer lookup), Amount, Currency, Stripe Payment ID, Project ID (from metadata), Status = "Paid", Paid At (from the Unix timestamp in data.object.created, converted using Make's parseDate() with a Unix timestamp format). A Slack module sends a formatted message to #payments with the client name, amount, and a link to the Airtable record.

Example 2: GitHub Webhook → Deployment Notification to Airtable + Slack

A GitHub repository webhook fires on every push to the main branch. The payload includes the repository name, pusher name, commit SHA, commit message, and modified file list. A Make scenario receives this, filters to only process pushes where the branch is "main" (using a Filter module checking ref equals "refs/heads/main"), and then:

• Creates an Airtable record in a "Deployments" table with the commit SHA, message, pusher, timestamp, and repository name.
• Uses a Text Aggregator to join the modified files list array into a comma-separated string for the Airtable "Changed Files" field.
• Posts to a Slack #deployments channel with the commit message, pusher name, and a GitHub link to the commit.
• If the commit message contains the text "[urgent]", an additional Slack DM goes to the team lead.

Example 3: Typeform Submission with File Upload → Google Drive + Airtable

A Typeform webhook delivers a submission payload that includes answered questions and, for file upload questions, a URL to the uploaded file hosted on Typeform's servers. The Make scenario receives the payload, extracts the file URL from the answers array using an Array Iterator and a Filter on the field_type = "file_upload", then uses an HTTP Get File module to fetch the file content from the Typeform URL. A Google Drive Upload a File module stores the fetched file in a client-specific folder, using the client name (from another form answer) to construct the folder path. The Airtable Create Record step writes all form answers plus the Google Drive file URL (from the previous module's output) into a single clean record.

Make's webhook module gives you the raw payload — which means you are in control of every field, every nested object, and every edge case. That power comes with the responsibility to handle arrays, null values, and unexpected payload shapes explicitly in your scenario design.

Example 4: Calendly Webhook → CRM Contact + Follow-Up Sequence

Calendly sends a webhook on every event created, canceled, or rescheduled. The event.created payload includes the invitee's name, email, event type name, start time, and any questions they answered during booking. The Make scenario checks the event type name with a Router: a "Discovery Call" booking creates a HubSpot contact and deal, then triggers a sequence; a "Onboarding Session" booking updates an existing Airtable project record with the session time and sends a preparation email via SendGrid.

Webhook Response: Sending Data Back to the Caller

Some webhook integrations require your endpoint to respond with specific data — not just a 200 OK. Shopify webhook verification expects a 200 within 5 seconds. Slack slash commands expect a JSON response with the message to display. In Make, the Custom Webhook module has a "Send a Response" option that lets you configure the response body and status code. For Slack slash commands, the response module returns {"response_type": "in_channel", "text": "Your message here"} with the text populated from earlier modules in the scenario.

1. Create a Custom Webhook module in Make and copy the generated URL to configure in your triggering system.
2. Run a test event in the triggering system and use Make's "Run Once" mode to capture the payload structure.
3. Use Set Variable or a JSON Parse module to extract the nested fields you need from the raw payload.
4. Add a Filter module immediately after the webhook to validate required fields are present before processing.
5. Build the downstream modules (Airtable, Slack, HTTP, Google Drive) using the extracted variables as inputs.
6. Add an error handler route to the webhook module that logs failures to an Airtable error log and sends a Slack alert. For a complete guide to Make's error handling architecture, see Make scenario error handling.