Every click and every QR scan is POSTed to a URL you own as structured JSON — carrying HMAC signature headers your code can verify, retried on a backoff ladder when you're down, and logged attempt by attempt. This is the primitive behind our delivery guarantees, pointed at your own code.
Any route that accepts a JSON POST is a valid endpoint — a Lambda, a Rails controller, a Flask route, a Worker. Paste its URL, keep the signing secret, and verify deliveries in five lines of standard-library code.
In your own stack: any route that accepts an HTTP POST with a JSON body — a serverless function, an API route, a five-line Flask app. All it has to do is read the event and return a 2xx.
Console → Notifications → Add channel → Webhook. Paste your URL into the POST URL field and save. Copy the whsec_ signing secret when it's shown — that's the only time it ever appears — then hit Send test.
Attach the channel to the links and QR codes it should hear about — one campaign's codes, or every link you run. One endpoint per system or one for everything: channels are cheap; make as many as your architecture wants.
Every attempt — the immediate one and every retry — is recorded per channel with its HTTP result and attempt number. When someone asks whether the webhook fired at 14:02, you answer with a row, not a guess.
A non-2xx, a timeout or a refused connection schedules the next attempt automatically — 30 seconds, then 2, 10, 15 and 15 minutes. Six attempts in all, and the event id never changes, so de-duplication on your side is one dictionary lookup.
Not a bare ping: the full scan event — code, source, destination, tags, timestamp, device — arrives at your Endpoint 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…"
}Three headers on every delivery — webhook-id, webhook-timestamp, webhook-signature (v1, base64 HMAC-SHA256). Verify with any Svix library or a few lines of stdlib.
Each channel mints its own whsec_ secret at creation and shows it exactly once, like an API key. It is never readable again — not by you, not by support.
The signature covers id.timestamp.body over the exact bytes we send, so receiver-side verification matches without canonicalisation tricks.
Retries re-sign with a new webhook-timestamp while keeping the same webhook-id — replay-window checks keep working and de-duplication stays trivial.
Events leave the redirect plane through a queue, so a slow endpoint never slows a visitor — and the event is typically with you in seconds.
At-least-once delivery: a success that times out on the response may be re-sent. De-dupe on webhook-id and you will never double-count a click.
Recompute HMAC-SHA256 over "id.timestamp.body" — the webhook-id header, the webhook-timestamp header and the raw request body — keyed with the base64 part of your whsec_ secret, and compare it to the v1 value in webhook-signature. Any Svix verification library accepts the three headers directly, or it's about five lines of standard-library code; the verification docs at docs.xengo.io/api/webhooks/ have copy-paste examples.
Any 2xx status within the delivery timeout counts as delivered. Anything else — a non-2xx, a timeout, a refused connection — schedules the next attempt on the backoff ladder. Do the fast thing in the handler and the slow thing after you've responded.
The ladder retries at 30 seconds, 2, 10, 15 and 15 minutes — six attempts covering roughly 45 minutes. An outage longer than that exhausts the ladder for events raised early in it, and each terminal failure is recorded in the delivery log, so you know exactly which events need reconciling from analytics.
No. The whsec_ secret is shown once, at channel creation, and is never returned by the API afterwards — deliberately, the same way API keys work. If you lose it, create a new webhook channel (which mints a fresh secret) and retire the old one; that's also how you rotate.
Rarely, yes — delivery is at-least-once by design. If your endpoint processed an event but the response timed out, the retrier can't tell success from failure and sends it again. The webhook-id is identical on every attempt, so de-duplicating on it makes your processing exactly-once.
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 POST URL and a Send test between you and your first signed event.