deploy notes
Automation

How to receive and test your first webhook in Make

Create a Make webhook, send a small JSON request, verify its mapped response, reject invalid data, and stop both the scenario and the webhook afterward.

Beginner7 min read
In this guide

A webhook gives Make an address that another app can send data to. That incoming request can start your scenario immediately—for example, when a form receives an enquiry.

Here you will send a fictional enquiry yourself and make Make return its request ID. Seeing that same ID come back proves that your data reached the module and was mapped into the response. You will also reject an invalid enquiry and close the test endpoint afterward.

You need an existing Make account with available credits and a free active-scenario slot, a desktop browser, a text editor, and a Bash terminal with curl already available. That terminal can be on Linux, macOS, or Ubuntu in WSL on Windows. The commands below are for Bash, not PowerShell. Make Free is sufficient; no trial, server, or connected business app is needed. The Make interface was checked on September 25, 2026.

Use only the sample data. The temporary webhook will accept requests from anyone who knows its address. Keep that address private, do not put it in a public repository, and disable it when finished. A real integration should also use the authentication supported by its sender; this exercise does not connect a real form or process customer data.

Prepare one small enquiry

In your terminal, check that curl is available:

curl --version

If the command is missing, use an environment with curl before continuing. Create a new empty folder and enter it:

mkdir make-webhook-lab && cd make-webhook-lab

If that name already exists, choose a new folder rather than overwriting its files. In your text editor, save the following plain-text file as payload.json inside it:

{
  "request_id": "DN-LAB-A09-001",
  "topic": "Website check",
  "quantity": 2
}

This is JSON: a small set of named values. Text uses double quotes; the number 2 does not. Keep these exact values for the first test.

Create the receiving webhook

In Make, go to Scenarios → Create a new scenario and name it First webhook. Click the large + in the middle of the canvas. Search All apps for Webhooks → Custom webhook.

Click Create a webhook and give it a recognizable name, such as First webhook input. Open Advanced settings, find Data structure, and choose Create to define a structure. A structure tells Make what fields and types it should accept.

Name the structure Enquiry check. Use Generate, select JSON, and paste the contents of payload.json. Apply the generated fields, then check them:

  • request_id: Text; open this field and explicitly set Required → Yes.
  • topic: Text.
  • quantity: Number.

Generated fields are not automatically required. Selecting Required for the ID is what lets the later missing-ID test fail at the entrance.

Save the structure, select it in the webhook’s Data structure field, and save the webhook. Leave API key authentication and IP restrictions unset only for this short, synthetic exercise. Make displays a unique webhook address and starts listening for sample data.

Explicitly selecting the structure matters: simply letting Make detect a sample makes fields available for mapping, but does not impose this validation.

Send the sample

Copy the webhook address from Make. In the same Bash terminal, run:

read -r -s -p 'Paste your Make webhook URL, then press Enter: ' WEBHOOK_URL && printf '\n'

Paste the address at the prompt and press Enter. It will not be displayed. The variable WEBHOOK_URL holds it for the following requests; do not replace it with a URL printed inside a saved script.

With Make listening, send the file:

curl --include --max-time 20 --request POST --header 'Content-Type: application/json' --data-binary @payload.json "$WEBHOOK_URL"

POST sends the file’s contents, and the header tells Make that those contents are JSON. The response should contain an HTTP 200 status and Accepted. In the webhook module, confirm that Make has captured request_id, topic, and quantity. Save the module.

This first acknowledgement proves receipt, not the completed response we want next. If curl cannot read payload.json, check that your terminal is in the folder where you saved it. If it times out, return to Make, ensure sample listening is active, and check the copied address.

Return the ID through a second module

Click the + on the right of the webhook module and add Webhooks → Webhook response. Set Status to 200.

In Body, build this response using the mapped fields from the first module:

{"received":"[request_id token]","topic":"[topic token]","quantity":[quantity token]}

The bracketed phrases show where to insert Make’s field tokens; do not type those phrases as literal text. Type {"received":", select request_id from the incoming webhook’s mapping panel, then continue with ","topic":", the topic token, ","quantity":, the quantity token, and the final }. The text tokens sit inside quotes; the numeric quantity does not. Keep the simple sample values for this exercise.

Save the response module and the scenario with the toolbar’s save icon. Leave the scenario inactive for this manual check. Click Run once, then run the same curl command again.

You should now receive HTTP 200 and:

{"received":"DN-LAB-A09-001","topic":"Website check","quantity":2}

In Make, open each module’s operation bubble and check its input/output. If the body contains a bracketed phrase or an empty value, reopen Webhook response and select the actual field token. If you only get Accepted, check that the response module is connected, saved, and included in the run. Do not treat Accepted alone as proof that the mapped response ran.

Check active mode and reject bad input

Save the scenario and return to its overview. Set its schedule to Immediately as data arrives if needed, then switch Inactive to Active. This lets a request start a run without pressing Run once.

Save a second file named invalid.json in your lab folder:

{"topic":"Missing request ID","quantity":"not-a-number"}

Send it:

curl --include --max-time 20 --request POST --header 'Content-Type: application/json' --data-binary @invalid.json "$WEBHOOK_URL"

Expect HTTP 400 and a validation error. The required ID is missing and quantity has the wrong type. If it is accepted, check that the explicit data structure is selected and that request_id is required.

Now edit payload.json: change the ID to DN-LAB-A09-002, topic to Mobile check, and quantity to 1. Send that file with the earlier payload command. The returned body must contain the new ID and values. Open History in Make and check the successful Instant run; it should include both webhook modules. This distinguishes the active request from the earlier manual test.

Stop both the scenario and its incoming address

Switch the scenario to Inactive and make sure no execution or Run once listener is still running. Then open Webhooks in the left sidebar, select your named webhook, and switch the webhook itself off in its details.

These are separate controls. An inactive scenario can still have incoming data queued at its webhook. Stopping the webhook prevents further test requests from entering that queue.

Send the valid payload one last time. The disabled endpoint should return HTTP 400 with Webhook is temporarily disabled, and no new scenario execution should appear. Inspect Queue for any earlier pending test requests before ever reactivating it; turning a switch off does not erase them.

Clear the temporary terminal variable:

unset WEBHOOK_URL

You have now checked receipt, field mapping, validation, active execution, and stopping. Before attaching a real sender, use its documented authentication and payload format, then test one harmless event through to the intended destination. The returned ID here is an acknowledgement, not a completed business action.

← Back to automation guides