Check-in at the door
How staff check tickets in at the door: choosing a session, scanning a QR code with the camera or typing a code, what each result means, door alerts, and who may scan which session.
For the Full Stack package
The door page
Check-in opens at /en/dashboard/check-in. Staff choose the event and its session, and the page shows whether doors are open, how many are checked in out of how many are expected, the latest scans and the alerts waiting. Doors count as open from two hours before the start, or once anyone is in, until the end. The page lists the sessions of published and sold-out events that ended less than 24 hours ago.
Check-in needs a connection: there is no offline queue to replay later, and the page pauses while the connection is gone.
Scanning a ticket
- Enable camera and point it at the ticket's QR code, or type the code in Enter code manually: a ticket reference such as
TKT-1042-1works as well as the QR code's text. The camera stays off until it is turned on, and its frames never leave the device. - The ticket is checked first without letting anyone in, and the result shows the holder, the seat and the ticket type.
- Confirm check-in admits it. Next ticket clears the result for the next person.
The camera is read in the browser with its built-in barcode reader, or with jsQR where the browser has none. A browser that cannot use a camera here still checks typed codes.
What each result means
| Result | Meaning |
|---|---|
| Ticket valid | It can be admitted. Nothing happens until Confirm check-in. |
| Checked in | Admitted now. |
| Already admitted | It was let in before; the result says when and by whom. |
| Wrong event | The ticket is for another event or session. |
| Ticket void | Refunded, waiting for a refund, voided, unpaid, or its event was cancelled. |
| Ticket not found | No ticket matches the code. A reissued ticket's old QR code reads this way. |
- A ticket is admitted once per session, whatever happens: two doors scanning it at the same moment let it in once, and the second sees who did.
- A dropped connection is safe to retry: the same attempt is sent again, so nobody is admitted twice.
- A refund or a reissue made a second before the scan wins.
Door alerts
A scan that ends as already admitted, wrong event or void counts as needing attention until someone presses Acknowledge on the door page. The overview adds them to its own count, and while the workspace's check-in alerts switch is on, each one rings the bell of every member who can publish events. Every scan is logged, without the code itself.
A fresh seed has 1,127 admissions and 8 alerts waiting: City Fest has 27 of its 50 tickets in and 3 alerts, and each other organiser has a door open now.
Who may scan which session
- Every check-in step needs
checkin.scan. The seeded Owner, Manager and Check-in roles hold it. - A member who can edit or publish events (the seeded Owner and Manager) may scan every session. Anyone else, such as the Check-in role, scans only the sessions assigned to them, and is told so when none are.
- Sessions are assigned on the member's page under Team, in Check-in sessions, by a member who may edit the team (
admins.edit). - The seeded check-in account scans City Fest and Design Talks at Northline Events and Winter Science Weekend and Winter Lights Trail at Meadow Days; its sign-in details are in the installation guide.
Limits
Each staff member may make 120 check-in requests a minute from one address, so a scanner is not a way to try codes. Behind a reverse proxy, set TRUST_PROXY=1 in the API's .env so the address is the scanner's own.
The routes behind it
POST /api/admin/check-in/validatelooks at a ticket and admits nothing;POST /api/admin/check-in/admitalso takes aclient_request_id(a UUID per attempt) and answers the original admission when it is sent again. Both take{ session_code, code }; a session's code is the event's slug followed by-main(design-talks-main).- Refusals: 404
NOT_FOUND, 409WRONG_SESSION, 409TICKET_VOID, 409ALREADY_ADMITTED, 403session_not_assigned, and 429 beyond the rate limit. GET /api/admin/check-in/sessions/:code/summaryand/scansread the door's figures and its 20 latest scans;POST .../acknowledgeclears its alerts.PUT /api/admin/session-staff/:codesets who scans a session.