Illustrative example. This walkthrough is hypothetical and is provided to demonstrate how yas.sh features could be applied to an events team. It does not describe a real customer, and all figures, metrics, timings, and quotes are illustrative only and do not represent actual customer results.
The hypothetical scenario
In this example, a fictitious events company ("EventFlow") runs conferences and trade events across Europe — 14 events a year, from 300-person workshops to a 3,000-attendee flagship conference with 40 sessions over two days.
The problem
Check-in was a paper-and-sticker operation. Attendees queued at the door while staff matched names against printed lists; badges carried a static QR that pointed at the event homepage — informative, but useless for session-level operations. Three failures were chronic:
1. The door. Peak-hour queues ran 25–40 minutes. The bottleneck was the name lookup, not the scanning.
2. Session updates. Every agenda change (room swaps, speaker changes, sold-out sessions) required updated signage — and printed signage couldn't be updated at all. Static QRs on session boards pointed at a generic page that never changed.
3. Zero session data. The organizers knew how many tickets sold and almost nothing about what attendees actually did: which sessions pulled, when people arrived, where the door was busiest.
The requirements
- One gesture for attendees — scan, move, done.
- Dynamic targets — badge and signage codes must be re-targetable without reprinting.
- Session-level measurement — scans per session, per hour, per device.
- Offline tolerance — door staff operate in halls with flaky Wi-Fi; the scan itself must never depend on the venue network.
The solution
EventFlow rebuilt check-in around dynamic QR codes on the existing infrastructure: badge printers, a hallway of posters, and yas.sh behind the scenes.
Badges: each badge carried a code pointing at a short link per attendee group (speaker, sponsor, general). Session doors used one code per session board:
# one link per session board, re-targetable any time
curl -X POST https://yas.sh/api/v1/links \
-H "Authorization: Bearer yas_live_..." -H "Content-Type: application/json" \
-d '{"originalUrl":"https://event.flow/session-14-agenda","customAlias":"s14","title":"Session 14"}'
# agenda change at 09:40 — re-target, no reprint
curl -X PATCH https://yas.sh/api/v1/links/<id> \
-H "Authorization: Bearer yas_live_..." -H "Content-Type: application/json" \
-d '{"originalUrl":"https://event.flow/session-14-updated"}'
The door: staff scanned badges with a generic scanner app pointed at the code — the redirect itself resolved to a per-session check-in URL carrying the attendee ID in the path. Because the redirect is a plain HTTP call, it worked on the venue's flaky network; the check-in write happened client-side in the venue app.
Print quality: session board codes were generated at 1024px with generous quiet zones (the print rules) — readable from 3 meters on poster board.
Results
| Metric | Before | After |
|---|---|---|
| Peak door queue | 25–40 min | 3–8 min (22 min faster) |
| QR reprints per event | 6–10 (signage) | 0 — all retargeted digitally |
| Session attendance data | none | scans per session, per hour |
| Agenda change turnaround | print + staff walk | 40 seconds in a dashboard |
| Total scans (flagship) | n/a | 1,200+ |
The data surprised the organizers: the "must-see" keynote pulled only 60% of its registered audience, while a breakout on AI tooling hit 110% (standees). Next year's session planning runs on that evidence instead of gut feel.
The per-hour scan series also showed the door's true peak was 09:20–09:40 — the team moved the welcome coffee earlier and rebalanced staff, cutting the worst queue further.
What the team says
"The badge is the same plastic card as before. The difference is that every code on it is alive — it points where we need it to point, when we need it to point there, and it tells us who scanned what. We will never print a static QR again."
— Head of Operations, EventFlow
Lessons for event teams
- Dynamic beats static everywhere in events — sessions, agendas, and schedules change; codes that can't change force reprints.
- The door bottleneck is name lookup, not scanning — remove the lookup, not the scanner.
- Scan data is attendance data — per-session series replaces anecdote with evidence for the next year's program.
- Print discipline pays at the door — size and quiet zone decide whether a 3-meter poster code works.
Run your event the same way
The QR endpoint generates print-grade codes in one call; short links make them dynamic; analytics turns scans into decisions. The QR for business guide has the print specs EventFlow used.
The principles this illustrative scenario demonstrates
This scenario is illustrative — a realistic, hypothetical walkthrough — not a claim about a real client. It exists to show the reusable principles behind a dynamic QR check-in. The core ideas: every attendee gets a dynamic QR tied to their registration, the QR records a scan on arrival, and staff watch a live count so they can adjust capacity or staffing in real time. The same pattern — a dynamic code, a tracked scan, and a monitored threshold — generalizes to any event, venue, or queue, which is why the walkthrough is useful even though the specifics are illustrative.
Why dynamic codes fit event flows
Events are a strong fit for dynamic QR codes because the details always change. Attendee names move seats, sessions get rescheduled, registration links change, and reprinting codes for all of that would be impractical. A dynamic code stays printed on the badge or ticket while the destination behind it can be updated or re-mapped as plans evolve. Combined with the dynamic vs static comparison, the event case shows the decisive advantage: the printed artifact is permanent, and the live value behind it is flexible.
The measurement that makes it useful
The value of the dynamic QR in an event flow is the scan data it produces. Each check-in is a tracked event with a timestamp, so organizers can watch the arrival curve, spot a growing queue, and adjust — open more gates, add staff, or re-time sessions — before it becomes a problem. That is the same threshold-and-monitor pattern as the webhooks automation material: watch a number, react when it passes a threshold. Applied to check-in, it turns a list of badges into a live operational picture.
Taking the principles elsewhere
Because the scenario is illustrative, the practical payoff is in the transferable steps: design the flow before you print, use a dynamic code so the destination stays editable, track the scans so you can react, and monitor thresholds so you stay ahead of the crowd. Those four steps apply whether the event is a conference, a storefront, or a queue. That transferability — not any specific figure — is the point of the walkthrough.