Make webhook setup: capture leads in 45 minutes

In about 45 minutes, you'll have a Make webhook setup that catches a website inquiry the moment it is sent, checks that the submission has the fields your business needs, and records a safe test result. The stack is your existing form and Make, the automation tool that passes information between business systems without manual copying.

What you'll build

A webhook is a web address that catches data another system sends. Your form will send each new inquiry to that address. Make will receive it immediately, turn the submitted details into fields you can use, reject a badly shaped request, and place an accepted lead into a simple test log.

This guide deliberately stops before sending email, text messages, or changing a customer record. First prove the front door works. Then connect it to the software that stores your customers and sends the follow-ups, usually called a CRM.

By the end, you will have:

1. One custom webhook with a name you can recognize later.
2. A defined list of expected lead fields.
3. A filter that stops empty inquiries.
4. A test destination that shows exactly what arrived.
5. A checklist for security, duplicate submissions, and failures.

Make's official webhook guide confirms that a custom webhook normally starts a scenario immediately. That is the business advantage. A lead does not wait for somebody to check an inbox or for a scheduled import to run.

Stack and field plan

You need a Make account and a form that can send submissions to a webhook address. Look in the form's settings for Webhook, Notifications, Integrations, or Send data. If it has none of those options, you will need that form's native Make connection instead of this guide.

Write down the minimum information a useful inquiry must contain before opening Make:

Do not collect card numbers, account passwords, medical details, or private notes through this general-purpose route. Every extra field creates another item your business must protect.

Steps

1. Create the receiving address

In Make, select Scenarios, then Create a new scenario. Name it Website lead receiver. Select the large plus button on the canvas, search for Webhooks, and choose Custom webhook.

Beside the Webhook field, select Add. Enter website-leads-v1 as the webhook name. The version number gives you a clean naming path if the form changes later.

Make's current Webhooks app documentation says one webhook cannot serve multiple scenarios. Keep this address tied to this one receiving routine. Click Save, then copy the generated URL.

Treat that URL like an unlisted business number. Anyone who has it can try to send data to it, so do not paste it into a public document, screenshot, or support ticket.

2. Add authentication when your form supports it

If your form can send a custom request header, open the webhook settings and expand API Key authentication. Select Add API key, create a named keychain, and enter a long unique value. Make will not show the value again after creation, so store it in your approved password manager.

In the form's webhook settings, add that same value to the x-make-apikey header. A header is a label sent alongside the form data. Here, it works like a password that Make checks before accepting the request.

If the form publishes fixed sending addresses, add them under IP restrictions. An IP address identifies the server sending the request. Only use this restriction when the form provider documents stable addresses, since a changed address would block real leads.

Some simple form builders offer neither option. You can still test the workflow, but assume the URL may eventually be discovered. Never rely on a hidden URL as your only long-term control.

3. Define what a valid submission looks like

Open Advanced settings in the custom webhook. Beside Data structure, create a structure named Website lead v1. A data structure is the checklist Make uses to decide which fields and kinds of information it should accept.

Add these fields:

A Boolean is a yes-or-no value, shown as true or false. Mark submission_id, name, message, consent, and source as required. Make documents that requests failing a selected data structure are rejected with status code 400, which plainly means the sender submitted bad data.

This setup also catches an email in the wrong format before it reaches later steps. It does not prove the address belongs to the person. Validation checks shape, not honesty.

4. Send one complete sample

Return to the scenario and select Run once. Make now waits for a submission. Open your website form in a private browser window and send a test with every field filled. Use your own contact details and write WEBHOOK TEST, DO NOT CONTACT in the message.

Back in Make, a numbered bubble should appear above the webhook module. Select it and inspect the output. Confirm that the email, phone, message, consent value, source, and submission ID all landed under the right labels.

If a field is absent, open the custom webhook settings, select Detect new values, and send another complete sample. Do not map half a sample and hope the missing information appears in production. It will not create a reliable field for later steps.

5. Stop empty inquiries

Select the right edge of the webhook module and add Tools > Set multiple variables. Create a variable called received_summary. Map the submission ID, name, source, and message into it. This produces a visible test result without contacting anybody.

Now select the line between the webhook and Tools modules. Choose Set up a filter and name it Has contact route and message. Set the conditions so message exists and either email or phone exists. The filter is a gate. Submissions without enough information stop before they use later actions or clutter your customer records.

Select Run once and submit another valid form. Open the completed execution in Make and confirm the Tools module ran. Then submit a blank message if your form permits it. The webhook should receive the request, but the filter should prevent the Tools step from running.

6. Choose the right processing order

Open Scenario settings. Leave the default parallel processing in place when each inquiry is independent. Parallel means two leads arriving together can be handled at the same time.

Turn on Process data in order only when later submissions depend on earlier ones, such as numbered bookings with limited inventory. Make then waits for one run to finish before starting the next. That protects order, but a slow or broken run can hold up every request behind it.

Save the scenario. Set its schedule to Immediately as data arrives, then activate it. Submit one final test after activation. A test that works only while Run once is open is not a finished setup.

The part that breaks

The first common failure is a form that reports success even though the downstream routine later fails. Without a Webhook Response module, Make returns a simple 200 Accepted response when it accepts a request into the queue. That confirms receipt, not completion.

If the form needs a custom reply, add Webhooks > Webhook response as the last module. Keep it last. Make warns that placing it earlier can acknowledge the request before a later step fails, which can hide errors and consume extra credits. A credit is Make's billing unit for one small automation action.

The second failure is duplicate delivery. Forms and payment systems may retry when they do not receive a quick answer. Require a submission_id, then check that ID in your destination before creating anything. An identical ID should update the same test record or stop, not create a second lead.

The third failure is silent backlog. In Make, open Webhooks from the left menu, choose your webhook, and inspect Queue and Logs. A queue holds received requests until the scenario can process them. Make says standard webhook logs remain available for three days, so investigate failures promptly rather than waiting for the monthly review.

Copy this

Use this as the sample body when your form lets you configure its outgoing data. JSON is a plain-text format systems use to exchange labeled information.

{
  "submission_id": "lead-10482",
  "name": "Jordan Lee",
  "email": "jordan@example.com",
  "phone": "+15551234567",
  "message": "WEBHOOK TEST, DO NOT CONTACT",
  "consent": true,
  "source": "website-contact"
}

Keep files out of this first build. Make currently limits a webhook request to 5 MB, but large uploads also make failures harder to inspect. Send a secure file link as text only when the business process truly needs one.

Upgrade path

Once the receiver passes both tests, send its clean output to your CRM. The lead-to-CRM automation guide covers the next handoff and the follow-up controls. Keep the webhook as the front door so every source arrives in one known shape.

Review expected volume before adding several actions. The Make pricing breakdown explains how each module consumes credits, while Make versus Zapier helps if your form already has a direct connector elsewhere.

Then add monitoring. Check failed executions each workday, test the form after any website update, and keep a written owner for the webhook URL and key. For more builds that move information without manual copying, use the automation runbooks.

Your next build is simple: connect the validated output to one test customer record, send the same submission twice, and confirm you still have one record. That is the point where a working webhook becomes a dependable business process.