Webhook-triggered scenarios in Make run the moment data arrives — and we send it the moment the scan happens. Code, source, destination, tags, device: the whole event reaches your custom webhook in seconds, ready to fan out through routers, filters and every module a signed webhook could feed.
Make's Webhooks module exists for exactly this shape of integration: an external system pushes JSON, the scenario wakes up instantly. We're the push. There's no connector to hunt for and no polling interval to tune — paste one URL and the scenario is live.
In Make: create a scenario, add the Webhooks module as the first step and choose Custom webhook. Make generates a hook.eu1.make.com URL — copy it, and leave the webhook listening to learn the data structure.
Console → Notifications → Add channel → Make. Drop the URL into the Webhook URL field, save, then hit Send test — Make catches the sample and determines the data structure from it.
Attach the channel to the links and QR codes it should hear about — each scenario only sees the codes it exists to handle, and nothing else runs it.
Make shows you the scenario's execution history; the console's delivery log shows the other half — every POST we made to your webhook, with its response code, first attempt and retries alike.
Attach the Make channel to specific links and QR codes from the link drawer. A returns-label scenario never hears about the marketing campaign, and vice versa.
Not a bare ping: the full scan event — code, source, destination, tags, timestamp, device — arrives at your Webhook URL within seconds of the scan.
Every delivery carries Svix-compatible signature headers
(webhook-id, webhook-timestamp,
webhook-signature) signed with your channel's
whsec_ secret, and failures retry on a backoff
ladder for up to six attempts — with every attempt visible in
the console's delivery log. Verification docs →
{
"event": "click",
"source": "qr",
"code": "spring-launch",
"shortUrl": "go.yourbrand.com/spring-launch",
"title": "Spring launch pack",
"destination": "https://yourbrand.com/spring",
"tags": { "campaign": "spring-24", "sku": "SB-114" },
"createdAt": "2026-05-02T09:14:11Z",
"ts": 1752319441000,
"at": "2026-07-12T10:44:01+00:00",
"ip": "203.0.113.7",
"ua": "Mozilla/5.0 (iPhone; …)",
"referer": null,
"customerId": "cus_9f2k…"
}Webhook-triggered scenarios bypass Make's scheduling entirely — the run starts when our POST lands, typically within seconds of the scan.
Hit Send test while the webhook is determining its data structure and every event field becomes a mappable item in your scenario's modules.
Each POST carries Svix-compatible signature headers tied to your channel's whsec_ secret — verifiable in a scenario step if you need proof of origin.
If the webhook is unreachable, we retry at 30s, 2m, 10m, then 15m twice — six attempts in all, with the same webhook-id every time.
The Make webhook URL must be HTTPS and is checked when you save the channel, so a broken paste surfaces immediately.
Tag a link with campaign or SKU codes and they arrive inside the event — filter conditions and router routes can key on them directly.
No — you paste a custom webhook URL from Make's built-in Webhooks module, which ingests our POST natively. Nothing about the trigger is second-class: webhook scenarios in Make run instantly, which is exactly what a dedicated app would buy you.
When a custom webhook is newly created (or you click Redetermine data structure), Make listens for the next request and learns the fields from it. Use the console's Send test button at that moment and every field — code, source, destination, tags — becomes mappable.
Each scan is one POST, which starts one scenario run; how many operations that run consumes depends on how many modules your scenario executes. We never batch or digest events — if you want fewer runs, attach the channel to fewer links.
Yes. Deliveries are signed with your channel's whsec_ secret using Svix-compatible headers (webhook-id, webhook-timestamp, webhook-signature). Most Make users treat the unguessable hook URL as sufficient, but the headers are there when the scenario needs proof.
The failed POST is retried on a backoff ladder — six attempts spanning roughly 43 minutes — and every attempt is recorded in the console's delivery log with its response code. Delivery is at-least-once, so de-duplicate on the webhook-id header if a run absolutely must not repeat.
Smart URLs, dynamic QR codes and a full API — branded on your own domain, safety-screened, and tracked. Build, re-point and measure it all in one place.
Start free trialBranded short links on a domain you control — editable, screened, and tracked.
Branded QR codes you can re-point any time — never reprint the poster again.
$ curl -X POST api.xengo.io/v1/links { "domain": "go.acme.com", "url": "https://acme.com/…" } → 201 go.acme.com/aB3xK▋
Create and manage links + QR at scale, straight from your own tools.
14-day free trial, card required, cancel anytime. One webhook URL, and scans start scenarios.