In short
A gate is a door with somebody checking passes at it. You bind a phone to the gate, scan each arriving pass, and the platform answers with one of nine verdicts — admitted, re-entry, duplicate, revoked, void, not open, wrong day, over capacity, or not part of this event. The decision is made centrally, so two doors cannot both admit the same ticket.
The single most important thing to know before opening a door is that everything resets per event day. Capacity, re-entry allowances and duplicate detection are all counted within one day, not across the run of a multi-day event. A ticket that is spent on Tuesday is a fresh ticket on Wednesday if Wednesday is one of its valid days — and a venue that filled up yesterday starts from zero this morning.
On this page
Who can operate a gate
Three kinds of person can work a door: the owner of the event, an administrator, and a team member who has been given the gate-operating permission. Nobody else can claim a scan, and the check happens on every single one rather than once at the start of a shift.
Before scanning, the phone is bound to the gate. That binding is what puts a name on every admission — which door, which device, which operator — and it is what lets the console tell you afterwards that a ticket was first used at the north entrance at ten past nine. Release the binding when the shift ends.
The decision ladder
Every scan runs the same checks in the same order, and stops at the first one that fails. Order matters: a revoked ticket presented outside the window is reported as revoked, not as too early, because the ticket problem is the one worth telling the holder about.
The nine verdicts
| Verdict | What happened | At the door |
|---|---|---|
| Admitted | First entry of the day, recorded | Let them in |
| Re-entry | They have been in before today and the policy allows it. The entry number is recorded | Let them in |
| Duplicate | Already admitted today, and the policy allows no more | Do not admit. The verdict names where and when the first entry was |
| Revoked | The organizer withdrew the ticket | Do not admit. Refer them to the organizer |
| Void | The ticket was refunded | Do not admit. Refer them to the organizer |
| Not open | Before the window opens, or after it closes | Ask them to come back, or explain the event has closed |
| Wrong day | Valid ticket, but not for today. The verdict lists the days it is good for | Tell them which days theirs covers |
| Over capacity | The day’s capacity has been reached and this would be a first entry | Do not admit. Re-entries are still let in |
| Not in this event | The code is not part of this pass set at all | Check they are at the right event, and the right gate |
Every one of these — including all the denials — is written down. A refusal at a door is not something that vanishes because you moved on to the next person. If a dispute comes back an hour later, the record of what was scanned, where, when and what the answer was is already there.
What the gate screen shows
Open the gate from More Tools → Events & Access → Linxy Gate Q. The tile appears only on accounts that have been given gate permission. The top of the screen names the event you are checking tickets for; use Change event to switch. Tablets are the gate devices: on a tablet held sideways the camera sits on the left and the results on the right, and the whole screen is drawn 15% larger except the scan target. It also works on a phone.
Every ticket gets one clear answer in a large card beside the camera, with one short vibration for a granted ticket and two for a denied one on devices that vibrate. The scanner’s usual beep and buzz on every detection are switched off while Linxy Gate Q is open, so a ticket held in view doesn’t keep sounding. The card heading is always Access Granted (green) or Access Denied (red, or amber when the ticket is fine but it is the wrong time), with the reason underneath:
| Verdict | The screen says |
|---|---|
| Admitted | Access Granted — First entry today |
| Re-entry | Access Granted — Came back in, with the entry number |
| Duplicate | Access Denied · Already Used — with the gate and time it was first scanned |
| Revoked or void | Access Denied · Ticket Cancelled |
| Not open | Access Denied · Not Valid at This Time (amber) |
| Wrong day | Access Denied · Not Valid Today (amber) |
| Over capacity | Access Denied · Event Full |
| Not in this event | Access Denied · Not Valid for this Event — a real Linxy Mark, but not a ticket for this event |
A ticket held in front of the camera is checked once. Move it away to scan the next one; the card returns to Ready — Hold a ticket up to the camera. No result means no valid ticket. Send them to the box office. — after a few seconds. The counters read Access Granted, Came back in and Access Denied, and Recent scans lists each answer in plain words — for example “Access Denied · Already Used — AF-GA-0001 · 7:44 pm · first in 7:42 pm, Main Gate”.
Why the day matters more than the date
Counting happens within an event day, not across the whole event. Three separate mechanisms all follow that rule.
| Mechanism | Counted per day | Consequence |
|---|---|---|
| Re-entry allowance | Yes | A pass allowing two entries allows two each day |
| Duplicate detection | Yes | Yesterday’s admission does not make today’s a duplicate |
| Capacity | Yes | A room that filled yesterday opens empty today |
Separately, a multi-day ticket can name the specific days it covers. Where it does, a scan on any other day is refused as the wrong day, and the refusal lists the days that ticket is actually good for so you can tell the holder without going and looking it up. Where a ticket names no days, it is good on any day inside the event’s window.
Capacity, and what does not consume it
When the day’s capacity has been reached, a first entry is refused with the capacity verdict, and that refusal is recorded like any other. Capacity is optional; where the organizer set none, the check does not run at all.
Duplicates, and what to do about one
A duplicate verdict comes with two useful pieces of information: which gate the first entry happened at, and when. That is usually enough to settle the matter on the spot.
- First entry at another door, minutes ago. Someone has passed the pass back out, or a copy is in circulation. Hold it and call the organizer.
- First entry at your own door, seconds ago. Almost always a double scan. Let them in.
- First entry hours ago and the person insists they have not been in. Worth escalating — that is what a shared or copied ticket looks like.
Two doors scanning the same pass at the same instant cannot both win. The record is claimed atomically, and whichever arrives second is answered as a duplicate rather than admitted. There is no window in which a fast pair of scans gets two people in.
Working offline
A gate keeps working when the network does not. Open the gate while you’re online so the phone downloads the pass list. If the connection drops, or you turn on Work offline, the device decides from that copy and holds each admission until it can send it. The status at the top shows how many are waiting, and Send now in the amber banner sends them. Tickets the device let in while online are remembered on it, so the same ticket scanned again offline is answered Already Used.
| Online | Offline | |
|---|---|---|
| Who decides | The platform, for all gates at once | This phone, from its own copy |
| Event window and valid days | Checked | Checked, the same way |
| Counting | Per event day | Per event day, in the event’s timezone |
| Duplicate detection | Across every door | Only against scans this phone has seen |
| Capacity | The whole venue | Only this phone’s own first entries |
| Admissions | Recorded immediately | Held on the phone, then sent with the time of each scan |
When held scans are sent, the platform checks each one again against the full record and marks it as having come from the offline path. If another door admitted the same ticket while this phone was offline, the later entry is recorded as a conflict, with the gate and time that came first.
If the phone never downloaded the pass list, it can’t check anything offline: it shows an error and records nothing. Get a connection and open the gate again before admitting anyone.
Arrivals in a group
Where a scan represents a group rather than one person, the console shows the roster and waits for the operator to confirm who is actually present before recording anything. Confirming is a deliberate act, because the alternative — admitting a party of six on the strength of one scan — is exactly the thing a gate exists to prevent.
Symptoms, causes and fixes
| Symptom | Cause | Fix |
|---|---|---|
| Every scan says not in this event | The phone is bound to a different pass set | Release the binding and bind to the correct gate |
| You cannot claim a scan at all | You are not the owner and do not hold the gate-operating permission | The organizer has to grant it. It is checked on every scan |
| Valid tickets are all refused as not open | The event window has not started, or has ended | Only the organizer can change the window |
| A ticket says wrong day | It names specific days and today is not one | The verdict lists its days. Tell the holder |
| Re-entries are being refused at a full house | Someone has assumed capacity applies to them | It does not. Re-entries never consume a place |
| Duplicate on a pass that should allow re-entry | The allowance for the day is used up, or the pass set is single-entry | Check the policy on that pass set. It is per day |
| Two doors both scanned and only one admitted | Working as designed — the claim is atomic | The second is answered as a duplicate. Nothing to fix |
| Offline scans have not appeared in the console | They are still buffered on the device | Get the device online and send them. Do not re-scan the crowd |
Things people commonly get wrong
Related reading: Your passes, Events in the App, Types of Connection, and When something is not working.