QR code entry with multiple gates for an event in India
Run every entrance from an ordinary phone, either the Thrivia mobile app or a browser scanner opened from a link, with no per-gate licence and no scanner hardware. Each ticket in a booking carries its own QR code, its own index and its own check-in time, so a party of four is four codes admissible at four gates at four different times. A gate that loses signal writes each scan to a queue on the device and replays it when the connection returns, and a ticket already admitted comes back as a calm already-checked-in answer naming the time it first went through rather than a silent second admission. Gates are numbered and a ticket presented at the wrong one is refused with the number it belongs to. The limit to plan around is that two devices offline at two entrances can each admit the same ticket until one of them syncs.
Every ticket carries its own code
A family of four books once and arrives in ones and twos. A booking record here holds a tickets array, and each entry in it has its own qr_code, its own ticket_index, its own status of GOING or CHECKEDIN, and its own checkin_time. Four passes are four codes. Two can be admitted at the north gate at 6:40 and the other two at the service entrance at 8:15, and the booking reads two of four in between.
That is the shape the multi-gate question turns on. A single code per booking forces the whole party through one gate together, which is why the person at the front is standing there on the phone to a friend who parked. A code per ticket means the guest who arrived can walk in.
This page is about the door only. Selling the tickets, where the money lands, what a fest committee should list as separate events and what a marketplace commission actually buys are covered in ticketing software for event organisers.
How gates are numbered, and what that does not give you
Gates are numbered, and the numbering is deterministic rather than assigned. The event carries a gate count, every booking hashes to a gate number from it, and all the tickets in one booking share that number, so a family of four is never split across two entrances. A steward opens the scanner and picks which gate numbers that device is covering; picking none means it takes every gate. A ticket presented at the wrong entrance is refused with the number it belongs to, so the steward can point rather than argue. Two things to know before you plan around it. The gate count is not a setting you can reach yourself yet, so it is off unless we turn it on for your event, and the gate a scan happened at travels with the scan but is not kept on the guest record, so there is no per-gate report afterwards.
Online this costs you nothing. Every phone posts to the same server against the same guest list, the flip from GOING to CHECKEDIN is a single conditional update, and a ticket is admitted once no matter how many entrances you are running.
Offline it costs you something real. Two devices that have both lost signal are two queues that cannot see each other. The same ticket presented at both is admitted at both, and the conflict is only discovered when the second device syncs. The count comes out right afterwards, because the server rejects the replayed admission and the duplicate is recorded, but the second person is already inside. Nobody fixes that with software on the device: the two phones have no channel between them.
The practical version: one device per entrance, a person who stays at that entrance, and a phone that is charged. Volunteers swapping phones mid-evening is how a queue ends up on a device that has never loaded the roster.
A gate with no internet
When the phone has no usable connection, the scan is recorded on the device and treated as a success, because the guest is already through the gate, and it is labelled on screen as not yet synced. The queue is one small JSON file in the app's document directory, written through expo-file-system, with each row carrying the event, the booking, the moment of the scan and the device id. It survives the app being killed.
Reading that file can fail in several ordinary ways: a fresh install has no file, an app killed mid-flush can leave a partial write, and an older build can leave a row shape this one does not recognise. Every one of those resolves to an empty queue rather than an error, and the reasoning is written into the file: the gate must open even when the device storage is unhappy. A failed write costs persistence across an app kill, not the admission, because the entry stays in memory and still flushes on reconnect.
Replay runs oldest scan first. A row the server accepts is dropped, including the idempotent already-checked-in answer, which is an accepted replay. A row the server rejects for a reason that can never change, a cancelled booking or a code belonging to another event, is dropped rather than retried forever. A network failure stops the flush where it stands rather than burning the rest of the queue against a server that is not there.
One thing to do while you still have bars: open the event on each device so the roster is loaded. A scanner replays what it took offline, and it cannot fetch a guest list it has never seen. There are two scanners and both queue offline. The mobile app is one. The other is a browser scanner you open from a link we mint for the event, good for 48 hours and protected with a four to six digit PIN if you set one, which installs to the home screen, keeps its queue in the browser's own database and pushes it every thirty seconds once there is a signal. A borrowed phone at the back gate needs the link, not an app install.
The same ticket, presented twice
Two paths reach the same rule and answer it differently on purpose.
- The scanner answers calmly. A code whose ticket is already CHECKEDIN comes back as a success carrying
alreadyCheckedInand a message naming the ticket and the time it first went through. A code held up in front of a camera re-decodes several times a second, so a red failure would fire on a guest the steward had correctly just admitted, and a steward who sees that twice stops reading the screen. - The dashboard answers strictly. The per-ticket check-in endpoint throws on a ticket already checked in, and the controller maps that to 409 Conflict instead of letting it fall through to a 500, so a caller can tell a business rule from a server fault.
A ticket that has not yet been admitted carries a 30-second cooldown, scoped to that booking, that ticket index and the scanning device's IP. Inside the window the repeat scan is refused with an instruction to wait. That check deliberately runs after the already-checked-in branch rather than before it, for the reason above.
Each duplicate presentation is recorded with its time and the IP that took it, unless the same ticket was already logged from that IP seconds earlier, which keeps a code sitting in front of a camera from writing a row per decode. That record is the trail you read on Monday when one ticket was shared around a hostel.
Two phones scanning the same code in the same instant is handled in the database rather than in the app. The update requires the ticket to still be GOING and the booking to still be live, so exactly one scan flips it and the other is routed to the already-checked-in answer. A refunded or cancelled booking is rejected at the door outright.
Check-in flips one way
Once a ticket is CHECKEDIN nothing in the product flips it back. A repeat call on the booking-level path returns the original check-in time rather than restamping it, so attendance time can never drift forward, and there is no un-check-in for a steward to send.
A two-day pass sold as one ticket therefore admits on day one and reports already checked in on day two, with the Saturday timestamp attached. The pattern that works is a ticket type per day: Day 1, Day 2, and a both-days option that issues two tickets rather than one. Then Sunday morning is a scan, not a phone call to whoever has the dashboard open.
Who is allowed to hold the scanning phone
Team members sit in one of four permission buckets: full_access, operations, sales and door. A door seat holds two capabilities, reading the guest list and checking guests in. No CRM, no lead contact details, no event edit form and no money. The volunteer you handed a phone to an hour before doors cannot open a lead's phone number, and that is enforced on the route rather than by hiding a menu item.
Door seats do not consume an admin seat. They are counted separately from the plan's seat allowance, because a plan with two seats would otherwise be spent on two gate volunteers before anyone hired a salesperson.
The gate also keeps working when billing does not. The door check-in route carries an exemption from the frozen-subscription write block, so a creator whose subscription is frozen can still admit the people who already paid. Verifying and rejecting a manual payment is exempt too, so the desk keeps working. Whatever the dispute is about, it does not get settled by a queue of ticket holders standing outside.
How long a scan takes per guest
There is no published seconds-per-guest figure here, and the ones you find elsewhere are mostly a property of somebody's queue rather than of their software. What is worth knowing is what happens per guest, because that is what you can time on your own venue's network before the day.
- The camera decodes the code and the app validates its integrity locally.
- With a connection, one request per ticket goes to the server, which flips that ticket and answers with the guest's name, the ticket type and whether the rest of the booking is still outstanding.
- With no connection, the row is written to the device queue with a synchronous write to a small file and the admit decision is shown immediately, so a dead gate is not slower than a live one.
- A ticket already admitted returns the earlier check-in time instead of a failure, which is the same number of taps as a clean admission.
What actually costs time at an Indian gate is upstream of all of that: the guest scrolling a WhatsApp thread for the code with the brightness at ten percent. Tell buyers in the confirmation to screenshot the code, and put a second person in front of the scanner whose only job is to get phones out and screens bright. That is worth more than any throughput claim.
For a party arriving together, each ticket is its own presentation, so a booking of four is four scans. Four people at one gate is fine. Four hundred at one gate is a staffing decision, and the answer is more phones rather than a faster phone.
The printed list, the two pens and the WhatsApp group
Most multi-gate events in India run on a printed guest list per entrance, a volunteer with a pen, and a WhatsApp group where the gates shout at each other. For two hundred people through one door this is correct and costs nothing. It comes apart at the point where two entrances have to agree about the same person, which is the entire problem a second gate creates.
| How it works today | Where it breaks | What Thrivia does instead |
|---|---|---|
| A printed copy of the guest list at each gate, ticked with a pen. | The four copies cannot see each other. Somebody admitted at the north gate walks around and is admitted again at the east gate, and you learn it from the headcount rather than from a list. | Every phone scans against the same guest list, and the flip from GOING to CHECKEDIN happens once in the database, so the second presentation reports the time of the first. |
| One entry per booking on the list, ticked when the group arrives. | A party of four arriving in twos is a tick that means either two or four, and by 9pm nobody knows which. | Each ticket in the booking carries its own code and its own check-in time, so a booking sits at two of four until the rest turn up. |
| The side entrance has no signal, so it gets a list and no app. | That gate becomes an estimate. If you were using a scanner app that refuses without a connection, the volunteer starts waving people through, which is worse than the pen. | The mobile app writes each scan to a queue on the device and replays it when signal returns, and any failure reading that queue opens the gate with an empty queue rather than refusing. |
| A friend forwards their code to someone who did not buy. | The pen has no memory of it. Two names that sound similar get ticked and the shared code is never visible as a pattern. | Every duplicate presentation is recorded with its time and the scanning device's IP, and a 30-second cooldown on an unadmitted ticket stops a code being worked at one gate repeatedly. |
| Volunteers are sent the organiser's dashboard login so they can check people in. | One shared login at four gates means four people who can edit the event, read every lead's phone number and see the money. | Door seats hold guest list read and check-in and nothing else, and they do not consume an admin seat. |
| Somebody on the committee tracks which gate is busiest in the group chat. | You get a guess, and only for as long as anybody is typing. | Half fixed, and this is the half to plan around. Gate numbers exist and a wrong-gate ticket is refused with the right number on screen, but the gate a scan happened at is not kept on the guest record, so there is no breakdown to read afterwards. |
The move costs one evening: deciding your ticket types and their counts, adding the gate volunteers as door seats, and walking each phone through one test scan against a real booking while you still have all day to discover that a phone's camera is cracked.
What it costs
Thrivia is a monthly subscription with an included booking allowance rather than a commission per booking. Plans start at ₹2,999 a month plus 18% GST at the entry rung and rise with bookings and admin seats, with better effective rates on six-month and annual terms. Door seats are unmetered, so adding a sixth gate does not move the bill. The live catalogue is on pricing, and that page is the one to trust.
When this is the wrong tool for your door
- You need turnstiles, handheld scanner hardware or an access control system. Check-in here is phones running the app.
- You need re-entry, pass-outs or a scan on the way out. Check-in flips one way per ticket and there is no exit scan.
- You need per-gate reporting. Tickets are assigned to gates and a wrong-gate scan is refused, but the gate is not stored against the guest, so nothing tells you afterwards which entrance admitted whom.
- You need reserved seating with a seat map. Tickets are counted, not placed.
- You need to set the gate count yourself. Gate numbering ships, but there is no screen for it yet, so it has to be switched on for your event.
- You depend on Zapier, a public API or a calendar sync. None of those exist.
If your gate is a trailhead rather than a venue, the same queue behaviour is covered from that angle in booking software for trek organisers, where the roster has to be loaded in Dehradun for a gate at 2,000 metres.
Common questions
Can I run QR code entry across multiple gates at one event in India?
Yes. Any number of phones can scan the same event at once through the Thrivia mobile app, with no per-gate licence and no dedicated scanner hardware. All of them check against the same guest list, and the flip from GOING to CHECKEDIN happens once in the database, so a ticket presented at a second gate reports the time it was first admitted rather than being let through twice.
Does one QR code cover a booking of four people?
No. Each ticket in a booking carries its own QR code, its own ticket index, its own status and its own check-in time. A party of four gets four codes and can be admitted at four different gates at four different times, with the booking showing two of four until the rest arrive.
What happens at a gate with no internet?
The scan is recorded on the device and treated as a success, because the guest is already through the gate, and it is shown as not yet synced. The queue is one small JSON file in the app's document directory, keyed by event, booking, scan time and device id, and it survives the app being killed. Any failure reading that file resolves to an empty queue rather than an error, because the gate has to open even when device storage is unhappy. Rows are replayed oldest first when the connection returns. Open the event on each device while it still has signal, because a scanner can replay scans it took offline but cannot fetch a roster it has never loaded. The browser scanner queues the same way, in the browser's own database, and pushes every thirty seconds once a signal returns.
Can two gates admit the same ticket?
Not while they are online, because both phones post to the same server and only one scan can flip the ticket. It can happen while they are offline. There is no gate entity in the model, so two devices that have both lost signal hold two queues that cannot see each other, and the same ticket presented at both is admitted at both. The conflict surfaces when the second device syncs, and the duplicate is recorded, but the person is already inside. Keep dead gates apart and put the tickets that matter through an entrance with signal.
How do I stop ticket sharing and duplicate scans?
A ticket already checked in comes back as an already-checked-in answer naming the time it first went through, rather than admitting silently. On the dashboard path the same case returns 409 Conflict rather than a server error. A ticket that has not yet been admitted carries a 30-second cooldown scoped to that booking, that ticket index and the scanning device's IP. Every duplicate presentation is recorded with its time and that IP, which is the record you read afterwards when one code was passed around.
How long does QR check in take per guest?
Thrivia does not publish a seconds-per-guest figure, because the number belongs to your queue more than to the software. Per guest the app decodes the code and validates it locally, then either sends one request per ticket and shows the guest name and ticket type, or, with no connection, writes the row to the device queue with a single synchronous file write and shows the decision immediately, so a gate without signal is not slower than one with it. A ticket already admitted takes the same number of taps as a clean one. The real cost at the door is a guest finding the code in a WhatsApp thread, which is why a second person getting phones ready in front of the scanner does more than any throughput claim.
What permissions can I give event staff who only work the door?
There are four permission buckets: full access, operations, sales and door. A door member holds exactly two capabilities, reading the guest list and checking guests in, with no CRM, no lead contact details, no event editing and no access to payments. Door seats do not count against the plan's admin seat allowance. They are scoped by capability rather than by event, so a volunteer added for one night can check guests in at any event on the account until you remove them.
Does a multi-day pass work on day two?
Not as a single ticket. Check-in flips one way per ticket and nothing reverses it, so a pass scanned on Saturday reports already checked in on Sunday with the Saturday timestamp. Sell a ticket type per day instead, with a both-days option that issues two tickets rather than one.
Can I check guests in if my subscription payment has failed?
Yes. The door check-in route is exempt from the frozen-subscription write block, so a creator whose subscription is frozen can still admit people who have already paid. Verifying and rejecting a manual payment is exempt on the same grounds.