QR Code Webhooks in Action: 6 Real-Time Automation Use Cases
SMLLR's Webhooks feature pushes six different QR/scan events to your own server, Slack, or Zapier the instant they happen. Here's what each event is for, with real automation examples for restaurants, retail, and events.
The Short Answer
Webhooks (Pro plan and above) are SMLLR's real-time push channel: instead of your systems polling SMLLR's REST API on a schedule to check what happened, SMLLR sends a signed JSON payload to a URL you control the instant something happens — a QR gets scanned, a QR is created or edited, or a dynamic redirect rule fires. Register up to 10 endpoints per account under Settings → Webhooks & Slack, choose which of six event types each one should receive, and that's the whole setup — no server-side polling loop to write and maintain.
The Six Events, Plainly Explained
Every event shares the same envelope (an event name, a timestamp, and a data object) but each one fires for a different reason:
- **scan.created** — fires on every single QR scan. The workhorse event, with device, browser, and coarse location in the payload.
- **qr.created** — fires the moment a new QR code is saved from the dashboard.
- **qr.updated** — fires whenever an existing QR code's destination or settings change.
- **qr.scan_limit_reached** — fires exactly once, on the specific scan where a scan-limit redirect rule (Basic+) crosses from its limit URL into its fallback URL — not on every scan afterward.
- **qr.scheduled_redirect_fired** — fires on every scan that matches a scheduled/time-window redirect rule (Pro+).
- **qr.device_redirect_matched** — fires on every scan that matches a device-based redirect rule (Basic+/Pro+), and tells you which bucket matched: iOS, Android, or desktop.
Where This Actually Gets Used
A few concrete patterns, all buildable with the events above and nothing else:
- **Restock alerts.** A packaging QR code has a scan-limit redirect: the first 100 scans get a launch-day discount, everyone after gets sent to the regular product page. Subscribe an endpoint to `qr.scan_limit_reached` and the ops team gets pinged the exact moment the promo runs out, instead of checking the dashboard periodically.
- **Launch-day monitoring.** A new campaign QR goes live on a billboard or in a mailer. An endpoint subscribed to `scan.created` for that account means the marketing team sees the first scan land in real time — confirmation the placement is working, without refreshing analytics.
- **App-install funnels.** A QR code with a device redirect rule sends iOS scanners to the App Store and Android scanners to Google Play. `qr.device_redirect_matched` lets a growth team pipe iOS-vs-Android scan volume into their own attribution tooling as it happens, rather than reconciling it later from exported reports.
- **Change auditing.** An agency managing QR codes on behalf of several clients subscribes an endpoint to `qr.updated` so any change to a client's QR destination shows up in the agency's own internal log — useful for accountability when several team members can edit the same account.
- **Time-window campaigns.** A restaurant's QR menu redirects to a breakfast menu before 11am and a dinner menu after 5pm using a scheduled redirect rule. `qr.scheduled_redirect_fired` confirms the switch actually happened at the right time, which matters more than it sounds like the first time a timezone misconfiguration silently breaks a campaign.
Three Ways to Receive an Event
The event itself is identical regardless of destination — only the delivery format changes. A generic endpoint gets the raw JSON payload over HTTPS with an X-Smllr-Signature header (HMAC-SHA256) to verify it actually came from SMLLR — the standard choice for feeding your own backend, a data warehouse, or a custom integration. A Slack endpoint is a Slack Incoming Webhook URL — no OAuth, no app install — and SMLLR formats the same event as a one-line human-readable Slack message instead of raw JSON; see the dedicated Slack guide for what those messages actually look like. Zapier doesn't need anything SMLLR-specific at all — point Zapier's own built-in "Webhooks by Zapier → Catch Hook" trigger at a generic SMLLR endpoint URL and you're wired into 6,000+ apps without SMLLR needing a published app in Zapier's directory; see the Zapier automation guide for the exact steps.
No Lead Data, Ever
Every event payload is deliberately minimal — QR and scan analytics only (QR name, campaign, scan timestamp, device, browser, coarse country/region/city, target URL, depending on the event). None of the six events, under any circumstances, carries a scanner's name, email, phone number, or consent record from Lead Hub. This isn't a setting you could accidentally enable — it's a structural property of what SMLLR builds into the payload in the first place.
What It Costs
Webhooks, Slack, and Zapier are all available on SMLLR's Pro plan (₹4,999/month) and above — the same plan, same feature flag, no separate add-on. Up to 10 endpoints per account, generic and Slack combined. See what's in the payload and how signature verification works for the full technical reference.
Related Reading
Frequently Asked Questions
What plan do I need for QR code webhooks?
Pro plan and above (₹4,999/month). The same requirement covers webhooks, Slack, and Zapier.
How many events can one webhook endpoint receive?
Whichever subset of the six event types you choose when creating or editing the endpoint. New endpoints default to everything except the two highest-volume, fires-on-every-matching-scan events (scheduled and device redirects), which require explicit opt-in.
Does qr.scan_limit_reached fire every time someone scans after the limit?
No — it fires exactly once, on the specific scan where the QR crosses from its limit URL into its fallback URL. Every scan after that is a normal scan.created event, not a repeated qr.scan_limit_reached.
Can a webhook trigger an SMS or WhatsApp message instead of Slack?
Not directly from SMLLR, but the same generic webhook endpoint can point at Zapier, which can then trigger an SMS/WhatsApp action from its own app library.
How many endpoints can one account have?
Up to 10, shared between generic webhook endpoints and Slack endpoints.
Is there a delay between the event happening and the webhook firing?
No — the event is enqueued the moment it happens and delivered by a dedicated delivery process, deliberately kept off the scan-redirect path so a slow or unreachable endpoint never adds latency to an actual scan redirect.
What happens if my endpoint is down when an event fires?
SMLLR retries automatically. After 5 failed attempts, that specific delivery stops retrying and is logged as permanently failed — every attempt, success or failure, is visible in the delivery history for 90 days.