IFTTT's Webhooks service turns a web request into an applet trigger — and every click or scan of your links is a web request waiting to happen. Scan the QR on the shop door and log it to a spreadsheet, blink a light, ping your phone: whatever your applet's that is.
IFTTT calls it 'Receive a web request'; we call it a scan. Name an event, copy the trigger URL with your key in it, paste it into the console — from then on, every scan you route to the channel fires the applet with three ingredients attached.
In IFTTT: Create → If This → search for Webhooks → Receive a web request, and give the event a name. Your trigger URL — maker.ifttt.com/trigger/[event]/with/key/[your key] — is on the Webhooks service's documentation page.
Console → Notifications → Add channel → IFTTT. Put the full maker.ifttt.com URL into the Webhook URL field, save, then hit Send test and watch the applet's Then That side run.
Attach the channel to particular links and QR codes — the door QR triggers the arrivals applet, and nothing else does.
The QR you print is permanent; where it points isn't. Change the destination any time in the console and the printed code keeps working — while the same scan keeps firing your applet.
Your IFTTT channel lives on the Notifications page beside Slack, Zapier and the rest — named per applet, testable with one click, pausable without losing the URL.
Each trigger carries value1 (the link's title), value2 (the short URL) and value3 (the destination) — the fields IFTTT lets an applet use directly.
The request fires as the redirect completes; the applet runs as soon as IFTTT processes it. No polling, no digest.
The maker.ifttt.com URL is checked when you create the channel, so a mistyped key fails at set-up rather than silently in production.
If IFTTT's endpoint errors, the delivery retries on a backoff ladder — up to six attempts over roughly 43 minutes, each logged.
Every attempt is recorded in the console's delivery log with its response code — 'did the applet get pinged?' has an answer.
The same scan can fire the applet, post to a chat channel and hit a signed webhook at once — channels stack freely.
No — xengo isn't a published IFTTT service. You use IFTTT's own Webhooks service ('Receive a web request') and paste its trigger URL into the console. The applet fires exactly as if a native service triggered it; the difference is only where the URL comes from.
Three ingredients, matching what IFTTT's Webhooks trigger accepts: value1 is the link title, value2 the short URL, value3 the destination. That's enough for most applets — notifications, spreadsheet rows, smart-home actions keyed on which code fired.
Not through IFTTT — its Maker webhooks are built around the three-ingredient shape, so this channel deliberately sends only that. If you need the complete structured event (tags, device, timestamps) with signature headers, use the Zapier, Make, n8n or generic webhook channels; the same scan can feed those too.
No. IFTTT's trigger URLs embed your personal key and ignore extra headers, so signing them would be theatre — the key in the URL is the authentication. Keep the URL private, and use a signed channel alongside if you need cryptographic proof of origin.
Yes. Give each applet its own event name in the Webhooks service, create one xengo channel per trigger URL, and attach channels per link or QR code. The garden-gate code and the campaign flyer never cross wires.
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 trigger URL and the first scan fires it.
