Make Webhooks Explained

Direct answer: make webhooks let a Make.com scenario trigger when an external service posts data to a unique webhook URL. This guide explains how make webhooks work, how to send test payloads, verify and parse them, and build reliable automations using webhooks and APIs.

How make webhooks work

A webhook is a simple HTTP endpoint that receives POST requests from another system. In Make.com, you create a webhook trigger module that exposes a URL. When an external service posts JSON or form data to that URL, Make receives the payload, starts the scenario, and passes the data to downstream modules for processing.

Setting up a webhook trigger in Make.com

High-level setup steps:

• Create a new scenario and add the Webhooks trigger module.
• Choose the Incoming Webhook option and copy the generated URL (or create a custom one if supported).
• Save the scenario and run it in listening mode to capture a test request.
• Send a test payload (see examples below) and inspect the received structure in Make.

For a walkthrough of scenario modules and mapping, see the how to use Make guide and the API guide for common patterns. If you are evaluating Make as a platform, check the Make review for pros and caveats.

Send a test payload (curl and Node.js)

Use a simple curl command to POST JSON to the webhook URL while your Make scenario is listening. Replace the example URL with the webhook URL from your scenario.

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{"event":"deploy","status":"success","service":"api"}' \
  "https://hook.make.example/YOUR_WEBHOOK_ID"

Here’s a minimal Node.js example using fetch (Node 18+ or a fetch polyfill) to send the same payload:

const payload = { event: 'deploy', status: 'success', service: 'api' };

fetch('https://hook.make.example/YOUR_WEBHOOK_ID', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(payload)
})
  .then(res => res.text())
  .then(console.log)
  .catch(console.error);

Parsing payloads and mapping fields

After Make receives a webhook, it shows the raw payload and creates keys you can map into subsequent modules. Common tasks:

• Use the JSON module or the built-in mapper to extract nested fields.
• Convert strings to numbers or dates with parsing functions before using them in conditions.
• Use filters or routers to branch scenarios based on event type or status.

Security: validating and hardening webhooks

Webhooks are public endpoints by nature. Protect them using these standard practices:

• Require TLS (HTTPS) for incoming requests.
• Use a secret token: have the sender include a header like X-Webhook-Token and compare it to a stored secret in Make or your middleware.
• Prefer HMAC signatures when available: verify payload integrity by recomputing a signature using a shared secret and comparing it to the header value.
• Reject unexpected HTTP methods (accept only POST) and validate Content-Type.
• Implement idempotency on the sender or in Make (dedupe by event ID) to handle retries safely.

Example of verifying an HMAC-SHA256 signature (Node.js) for a sender that adds the signature in the X-Signature header. This runs in your own middleware before sending to Make if you prefer that architecture:

const crypto = require('crypto');

function verifySignature(rawBody, headerSignature, secret) {
  const hmac = crypto.createHmac('sha256', secret);
  hmac.update(rawBody);
  const digest = `sha256=${hmac.digest('hex')}`;
  return crypto.timingSafeEqual(Buffer.from(digest), Buffer.from(headerSignature));
}

// Usage inside an Express app
// app.post('/relay-to-make', express.raw({ type: '*/*' }), (req, res) => { ... })

Testing, retries, and debugging

Key techniques for reliable testing:

• Use the scenario’s built-in request capture when available to inspect raw payloads and headers.
• Simulate retries from the sender side to validate idempotency handling.
• Log request headers and bodies in a safe environment (avoid logging secrets in plain text).
• When requests fail, inspect HTTP status codes and Make’s execution log for module-level errors.

Update: changing webhook URLs and schema

When you update a scenario or regenerate a webhook URL, update the sender configuration to point to the new URL. If the payload schema changes, update your mapping and add validation steps to avoid silent failures. For production systems, use a proxy or relay that can accept both old and new formats during migration.

Common pitfalls and troubleshooting

• Missing or incorrect Content-Type causes Make to parse payloads incorrectly—ensure senders use application/json for JSON payloads.
• Large payloads may be truncated or rejected; check platform limits in Make documentation and consider sending references to large objects instead.
• Clock drift affects HMAC/Timestamp-based signatures—allow a small tolerance window or sync clocks.

Closing recommendation

Start simple: create a webhook trigger in a development scenario, send test payloads with curl, and map a few fields to an action module. Add signature verification and idempotency as soon as you move to staging. For platform-specific details and to build scenario best practices, explore Make.com resources and tutorials. If you want a step-by-step walkthrough next, Learn how to use Make or review API patterns and compare platform behavior in the Make review. To continue learning and get practical experience, Learn webhooks with Make.com and experiment with small, safe payloads in a dev scenario.

Provider note: this guide references Make.com as the platform for webhook triggers. Use the platform’s documentation for any service-specific caveats and supported header conventions.