The event check in app that works at the door.
An event check in app does one narrow job, and it is not registration. Registration happens weeks before the event and records who said they would come; check-in happens at the door and records who actually arrived, when, and through which entrance. If you still need the first half, the forms, ticket types and payment, that is an event sign-up app. This page is about the second half: the door record, the QR scan that creates it, and the rules that keep it honest when the wifi drops and two volunteers scan the same ticket.
It is the door-side companion to the wider family of community and organisation apps, where the same attendee list goes on to feed memberships, volunteer rosters and fundraising. Whatever you call it, check-in event app, door app or scanner app, the requirements below are the same.
See what the door record needsThe short version
A scan log, a rule against double entry, and a mode that survives bad wifi.
An event check in app needs the ticket ID and tier, a check-in log with a timestamp, the entrance and the device for every scan, a duplicate rule that refuses a second entry without a human decision, a name lookup for when the QR code will not load, a walk-in flow that creates a registration on the spot, and an offline mode that queues scans and reconciles them later. Everything else, badge printing, session capacity, check-out for headcounts, is optional until your event needs it. The rest of this page is why, with the fields spelled out.
Two records
Registration and check-in are two different records.
Most "check-in problems" turn out to be a registration list being asked to do a job it was never designed for. A registration is a promise and, sometimes, a payment; a check-in is a fact about a person standing in front of you. They are created at different times, by different people, and they answer different questions afterwards.
| Registration record | Check-in record | |
|---|---|---|
| When it is created | Days or weeks before the event, by the attendee. | At the door, by a staff member or volunteer, or by the attendee at a self-service stand. |
| What it proves | That someone intended to come and, for paid tickets, that they paid. | That a specific ticket was presented at a specific entrance at a specific time. |
| Core fields | Name, email, ticket type, quantity, answers to your form, order and payment status. | Ticket ID, check-in time, entrance, device or operator, method (scan, lookup, walk-in), result. |
| Can it change? | Yes. Edits, transfers, refunds and cancellations right up to the event. | Append only. A mistaken check-in is reversed by a new entry, never by editing the old one. |
| The question it answers later | How many people registered, and what they told us. | Who actually showed up, when, and where the queue built up. |
The practical consequence: the check-in record links back to the registration by ticket ID, but it must not depend on the registration staying still. A ticket refunded an hour before doors open should scan as void, and a transferred ticket should scan under the new name, without anyone re-importing a list.
The door record
What an event check in app needs to capture.
Every event adds its own extras, but the base record that a conference badge desk, a community fundraiser and a 5K packet pick-up all share looks the same:
- The ticket or registration ID the attendee presented, which is the value inside the QR code
- The ticket type or tier, and what it grants: which days, sessions or areas
- The check-in time from the device, plus the time the server received it
- The entrance, gate or desk, and the device or operator that recorded it
- The method: QR scan, name or email lookup, or walk-in
- The result: admitted, duplicate, void, wrong day, or capacity reached
- For group tickets, the party size and how many of the party have arrived so far
- Flags the door needs to see: VIP, accessibility request, minor with guardian, unpaid balance
- A reversal entry if the check-in was a mistake, with who reversed it and why
The rules that keep the record honest
Fields are easy to list. The rules around them are what separate a check-in app from a form with a camera:
One ticket, one entry
A second scan of the same ticket must show who checked it in, where and when, and require a deliberate override. Silent acceptance is how two people get in on one ticket.
Append, never edit
Check-ins are events, not a checkbox on the attendee. A wrong scan is reversed by a new row, so the history survives and the headcount can always be reconstructed.
Validate the ticket, not the name
The scan checks the ticket ID's current status (valid, refunded, transferred) and its access rights for this entrance, this day and this session.
Server time wins
Device clocks drift and volunteers fly in from other time zones. Store both timestamps and run every report on the server's.
Least data on the door
The scanning screen shows the name, the tier and a photo if you use one. It does not need the email, the phone number or the dietary answers.
Keep the fallback one tap away
Screens crack, brightness is low, the email never arrived. Name lookup belongs on the same screen as the scanner, not three menus deep.
"Least data on the door" is more than good manners if any of your attendees are in the EU. Article 5(1)(c) of the GDPR requires personal data to be "adequate, relevant and limited to what is necessary" for the purpose, and Article 5(1)(e) says it may be kept in identifiable form for no longer than that purpose needs. A check-in app that syncs ticket IDs, names and tiers to the door devices rather than the whole registration export, and that clears the local copy after the event, is the easy way to comply. Read Article 5 of the GDPR on EUR-Lex.
The scan
How QR code check-in actually works.
The QR code on a ticket is a delivery mechanism for one value: the ticket ID. Everything that makes check-in fast or slow happens on either side of that scan.
- 1
Generate
At registration, each ticket gets a unique ID and a QR code that encodes it, or a signed token derived from it.
- 2
Deliver
The code reaches the attendee by email, in a wallet pass, inside the registration app, or on a printed ticket.
- 3
Scan
The door device reads the code with its camera and extracts the ID. A good scanner copes with a dim phone screen and a crumpled printout.
- 4
Validate
The app checks the ID against the synced list: does it exist, is it paid, is it valid for this entrance, day and session, and has it been used?
- 5
Record and show
The app writes the check-in entry and shows a large green or red result with the name and tier, readable from arm's length.
- 6
Fall back
If the code will not scan, the operator searches by name, email or order number on the same screen and records the check-in as a lookup.
What the QR code should contain
An ID, not a person. Encoding the attendee's name, email or ticket tier in the code means anyone with a screenshot can read it and anyone with a QR generator can forge it. The event check in app QR code should carry a random ticket ID that only means something against your list, or a token signed by your server so that a forged code fails validation even when the device is offline. The tier, the name and the access rules live in the list the device has synced, not in the code.
On the reading side, the camera module a React Native app uses for this reports each successful read through a callback and decodes QR alongside EAN, Code 128 and PDF417, so the same scanner screen can read a printed wristband barcode as well as a phone screen. See the barcode types in the Expo Camera documentation.
When the scan fails
It will, several times an hour: a cracked screen, brightness turned down, an email in a spam folder, a partner who has the tickets and is still parking. The fallback is a search box on the scanner screen that finds people by name, email or order number and records the check-in with the method set to lookup, so the report can tell you how often the codes failed. The mechanics of the scanner screen itself, the permission prompt, keeping the session alive between scans and stopping it when the screen closes, are a separate topic covered in using the camera for QR scanning.
Offline first
Offline check-in, and what happens when two devices disagree.
Venue wifi is the least reliable thing at any event, and cellular signal in a basement ballroom is worse. An event check in app has to sync the list before doors open, accept scans with no connection, queue them, and reconcile when the signal returns. That raises the one question a spreadsheet can never answer: what happens when two doors scan the same ticket while both are offline?
Ticket 4F7C scanned. Not seen on this device, so the local rule says admit. The scan joins the queue to sync.
Ticket 4F7C scanned again. This device has never seen it either, so it admits too. Nobody at either door can know yet.
The server keeps Door A's entry as the check-in, stores Door B's as a flagged duplicate, and both devices show the conflict. Staff decide what happens next; the record does not decide for them.
The rule that works: the earliest check-in in the server's order wins, every later scan is stored as a duplicate rather than dropped, and each device shows the conflict the next time it is online. Dropping the second scan hides the problem. Refusing to work offline creates a queue that is worse than the problem.
The queue
How many check-in stations do you need?
A queue at the door is arithmetic before it is software. The fastest app in the world does not help if three hundred people arrive in the same ten minutes and one volunteer is holding the only phone.
Try it
How many stations keep the line moving?
Pick how your door mostly works, then put in your numbers. The seconds per attendee are starting assumptions, not benchmarks: time twenty real check-ins at your own door and replace them.
Stations needed
2
stations clear 300 people in about 25 minutes, inside your 30-minute window
One station alone
50 min
to clear the whole list if nobody else is scanning
Per station
6/min
attendees each station admits at 10 seconds a person
Arrivals bunch up in the last ten minutes before a keynote or kick-off, so plan for the peak rather than the average, and keep one lookup-only station for the people whose codes will not scan.
Edge cases
Walk-ins, group tickets and check-out: where a simple list breaks.
A list of names with a tick box handles the ordinary arrivals at any door. The rest is where the queue forms, and each case needs a decision made before the event, not by a volunteer under pressure.
Walk-ins
A walk-in is a registration and a check-in created in the same minute. The app needs a short form (name, email, ticket type), a way to record a payment or mark the balance as unpaid, and it must issue a ticket ID so the same person can be scanned again at a session door. Count walk-ins separately in the attendance report; they are the number that tells you whether your registration deadline is doing anything.
Group tickets and plus-ones
A ticket for four rarely arrives as four people at once. The record needs a party size and an arrived count, and the door screen needs to say "2 of 4 checked in" rather than showing a single tick. Whether the rest of the party can enter without the named holder is a rule you decide in advance and the app enforces, not a judgement call at the door.
Check-out and headcount
For most events, check-in is enough. For anything with a safety headcount, a workshop with children, a venue with a hard occupancy limit, a multi-day festival with re-entry, you need check-out too, and "on site right now" becomes the number the venue manager asks for. Re-entry is a check-out followed by a new check-in against the same ticket, which is one more reason to store a log rather than a single checked-in flag.
Sessions, capacity and the people at the door
Multi-track events check people in twice: once at the venue, once at each session with a capacity. Session check-in is the same record with a session ID and a capacity rule that turns the screen amber when the room is nearly full. The people running those doors are almost always volunteers, and rostering them across shifts and entrances is a volunteer scheduling app problem that sits right next to this one. And if the same desk is also selling draw tickets for a fundraiser, keep that in a raffle app with its own numbering rather than bolting sales onto the check-in screen.
Scan methods
QR codes, name lookup, or wristbands?
QR is the default for a reason, but it is not the only option, and the right mix depends on how your attendees arrive and what they are carrying.
| Method | Speed at the door | What it needs | Where it fails | Best for |
|---|---|---|---|---|
| QR on the attendee's phone | Fastest when it works | A camera on the door device | Dead batteries, dim screens, the email that never arrived | Ticketed events where everyone registered in advance |
| Printed QR ticket or badge | Fast | A printer before the event, or on demand at the desk | Lost printouts, badge reprints, a queue at the printer | Conferences and anything with a lanyard |
| Name or email search | Slow, one attendee at a time | Nothing extra | Common names, typos, someone registered under a partner's email | Small events, and as the fallback everywhere |
| NFC or RFID wristband | Fast, and hard to share | Wristbands, compatible readers, encoding before the event | Cost, lead time, a reader that will not pair | Multi-day festivals with re-entry |
| Paper list and a pen | Slow | A printout | No duplicate check, no report, unreadable by the end | Twenty people in a church hall |
Picking an approach
Check-in tools, compared.
None of the fields above need a fancy tool, but most of the common ways of running a door make at least one of them impossible to get consistently.
| Approach | QR scanning | Works offline | Catches duplicates across devices | Custom fields and rules | Who maintains it |
|---|---|---|---|---|---|
| Paper list | No | yes, by default | No | yes, in pen | you, by hand |
| Spreadsheet on a tablet | No | depends | No | yes | you, and it drifts |
| Ticketing platform's check-in app | Yes | usually, with sync | Yes | locked to their ticket model | the vendor |
| Generic form builder | depends | depends | No | limited | you, bolted together |
| Custom-built check-in app | Yes | Yes | Yes | whatever your event needs | you |
Free vs. paid
Is there a free event check in app?
Yes, with a condition: the free ones come attached to a ticketing platform, and they only see the attendees who registered through it. Eventbrite includes its organizer app and mobile check-in with its events; publishing free events costs nothing, and paid tickets carry a 3.7% plus $1.79 service fee per ticket and a 2.9% payment processing fee per order, per its US pricing page as of September 2026. See Eventbrite's pricing page. That is a fair deal for a straightforward ticketed event, and other ticketing platforms bundle a free event check-in app on the same terms.
It stops fitting when your attendee list lives somewhere else, a membership database, a race registration system, a school roster, when you need fields or rules the platform does not model, or when the door has to do more than admit people. Even a build-it-yourself platform like Newly starts at $25 a month, so the question is rarely price; it is whether your check-in process matches someone else's idea of a ticket.
When to build your own
Building an event check in app that fits your event.
The honest reason to build your own check-in app is fit, not cost. A membership organisation checking members in against its own database, a race with packet pick-up and timing chips, a school event where every child needs a named guardian at check-out: none of those map onto a ticketing platform's idea of a ticket. That gap, a door process that no off-the-shelf tool quite fits, is what Newly is for: describe the record, the duplicate rule, the walk-in form and what the door screen should show, and it builds a real native app around your event instead of the vendor's.
Two practical notes for the scanner screen. The preview pane's cloud simulators have a webcam injection control that feeds your computer's camera to the simulated device, per the preview docs, which is enough to check the layout and the lookup fallback, but Expo's camera module lists itself as device only on iOS and Android, so treat a real iPhone through TestFlight as the test that counts for the scan itself. iOS builds are uploaded to App Store Connect for that, and there are no Android release builds today, which matters if your volunteers carry Android phones: plan for a small pool of iPhones or iPads at the door.
Sources
Where the specifics came from.
Four things on this page come from a primary source rather than general event-industry consensus:
FAQ
Event check-in apps, answered.
An event check-in app records who actually arrived at an event, when, and through which entrance. Staff scan the QR code on each ticket or look the attendee up by name, the app validates the ticket against the registration list, marks it as used, and shows a clear result. Afterwards it gives you attendance versus registrations, no-show numbers, and per-door or per-session counts. It replaces a printed list and a highlighter with a record that catches duplicate entries and keeps working when the venue wifi does not.
Start with the door record, not the scanner.
Check-in apps live or die on the boring parts: a log that cannot be edited into lying, a duplicate rule that holds when the wifi drops, and a lookup box next to the camera. Get those right, then build the app around them in Newly.