Restaurant Kitchen Alerts via QR Webhooks: Notify Staff the Instant a Table Scans

A diner scans the table QR code, the menu opens on their phone, and — from the restaurant's side — absolutely nothing happens. No one at the counter, on the floor, or in the kitchen knows that table just started looking at the menu, because a scan is a private moment between a phone and a webpage unless something is built to surface it. For a quiet two-table café that's rarely a problem; a server just watches the room. For a busy multi-section restaurant during a Friday dinner rush, that blind spot is exactly where pacing falls apart — the kitchen finds out a table is ready to order only when a server walks over and tells them, which is often minutes after the table actually engaged with the menu.

SMLLR's Webhooks feature (Pro plan and above) fires a scan.created event every single time a QR code is scanned, carrying the QR code's name, the timestamp, and coarse device/location details. Point that event at a Slack channel — using SMLLR's native Slack integration, which needs only a pasted Incoming Webhook URL and no app install — and a table's menu QR code being scanned shows up as a message in that channel within moments: "📱 Table 7 Menu was scanned from Koramangala, KA, IN on iPhone." Route the same event to a generic webhook endpoint instead, and it becomes raw JSON your own kitchen-display system or internal dashboard can consume directly, if you have the engineering resources to build that consumer.

Print a distinct QR code per table (or per section, for a lighter-weight setup) so the alert names exactly which table triggered it, not just "a table somewhere." Create a Slack channel visible on a kitchen-side tablet or a pass-through screen — the same way many kitchens already run an order-ticket display — and paste that channel's Incoming Webhook URL into SMLLR's Settings → Webhooks & Slack, subscribed to scan.created. From that point on, every table scan appears where the kitchen and floor staff are already looking, without anyone needing a SMLLR dashboard login.

A scan alert doesn't tell you what a diner ordered — it tells you a table started engaging with the menu, which turns out to be useful on its own for a few concrete things:

It's worth being precise about what this is: a scan alert confirms a menu was opened, nothing more. It doesn't know what dish was chosen, whether the table actually placed an order, or how many people are seated — that information lives in your POS or ordering system, not in SMLLR, and a scan.created webhook is not a POS integration or an order-management feed. A restaurant wanting scan alerts to trigger something inside an existing kitchen-display system needs to build a small consumer for the generic webhook's JSON payload on their own infrastructure; SMLLR delivers the event, but doesn't natively speak to any specific POS or KDS vendor. For most restaurants, routing the event to Slack — no custom code required — is the realistic starting point, and it's also worth knowing upfront that scan.created fires on every scan with no built-in throttling, so a single high-traffic QR code during a packed dinner service can post frequently; keeping the channel scoped to a specific table, section, or a slower-moving code keeps it useful rather than noisy.

Webhooks and Slack are both part of SMLLR's Pro plan, ₹4,999/month, with up to 10 endpoints per account shared between generic and Slack destinations. There's no separate charge for choosing Slack over a generic endpoint, or for running both at once — a kitchen-facing Slack channel and a generic endpoint feeding an internal dashboard can both subscribe to the same scan.created event simultaneously. See the full Webhooks overview for all six event types SMLLR can push, or the Slack notifications guide for exactly how the message formatting works.