In short
A pass is the right to walk through a door, held against your account. It lives in your wallet, it can be handed to somebody else while it is still unspent, and it is settled at the gate by a scan. Passes carry a tier and sometimes a seat, and the organizer can withdraw one at any time.
The point most people miss is what a transfer actually moves. Handing on a ticket changes who holds it and nothing else. The Linxy Mark that carries the pass, and the Dynamic Link behind that Mark, never leave the organizer — which is why a transferred ticket cannot be tampered with by either party, and why the artwork you were sent keeps working in the new holder’s hands without being re-issued.
On this page
What a pass actually is
A pass is a row that connects three things: an event, a piece of artwork, and a person. The artwork is a Linxy Mark. The person is the holder. The event supplies the rules — when the doors are open, how many times you may come and go, which days your pass covers.
Two labels ride along with it. A tier names the class of admission, which is whatever the organizer decided to call it: general admission, early bird, crew, patron. A seat is an optional string, used where seating is assigned. Neither of these changes what the pass is permitted to do — they describe it, they do not empower it. A tier called VIP opens exactly the same doors as one called GA unless the organizer has built a separate gate for it.
What is deliberately not part of a pass is ownership of anything. You hold the pass. The organizer owns the Mark, the link and the event.
Where your passes live
On the web, your passes are at Tickets & Passes in your account. In the Linxy App they are under More Tools → My Tickets & Passes, and also inside LinxyPass, in the same place as the sites you have enrolled but kept in their own section — passes and enrolled sites are different things and are never mixed into one list.
A pass appears in your wallet the moment the organizer issues it against your account, or the moment you accept a transfer. You do not need to do anything to claim one that was issued directly to you.
The states a pass can be in
Three statuses are recorded against a pass, and there is a fourth condition that is not a status at all but behaves like one.
| Condition | What it means | Set by | Reversible? |
|---|---|---|---|
| Valid | The pass is live. Every pass starts here. | Issued this way | — |
| Void | Withdrawn with a reason, and usually a refund reference. The audit trail records when and why. | Organizer | Yes, by the organizer |
| Revoked | Switched off. No reason recorded. | Organizer | Yes, by the organizer |
| Used | Not a stored status. It is worked out from the entry record — a pass is spent because it has been admitted, not because a flag was set. | The gate | No |
That last row is the one worth sitting with. Because being spent is derived from history rather than written down, it cannot be undone by an organizer flipping a switch. An organizer can put a revoked pass back to valid. Nobody can un-scan a pass. If somebody is admitted by mistake, the fix is a fresh pass, not a repair to the old one.
Handing a pass to somebody else
You start a transfer from the pass itself. The platform gives you an eight-character claim code, which you pass to the other person by whatever means you like. They enter it and the pass becomes theirs.
The code is drawn from a restricted alphabet: capital letters and digits, with I, O, zero and one left out entirely. That is not decoration. It means a code can be read aloud across a noisy room or written on a napkin without the classic confusions, and it is why entering a code is not case-sensitive.
Requesting a transfer twice for the same pass does not produce a second code. The first one is handed back to you unchanged. A pass can only ever have one live claim code, so it is impossible to accidentally promise the same seat to two people.
A pending code can be canceled by whoever created it, and canceling costs nothing. Until somebody claims it, you still hold the pass — issuing a code is an offer, not a handover. You can walk through the door with a pass that has an outstanding claim code against it, and the code simply stops working.
You cannot claim your own code.
When a pass will not transfer
Four distinct conditions block a transfer, and they produce four different answers rather than one generic refusal.
| Reason | What has happened | What can be done |
|---|---|---|
| Not valid | The pass has been voided or revoked by the organizer | Ask the organizer. They can restore it |
| Bound to a person | The pass was issued tied to an identity through Linxy Fusion | Nothing. This kind of pass is never transferable, spent or not |
| Used | An ordinary pass with no named days has already been admitted once | Nothing. It is spent |
| All days used | A multi-day pass has been admitted on every day it covers | Nothing. It is spent |
The distinction between the last two carries a consequence that reads backwards at first glance: a pass restricted to named days stays transferable for longer than one with no restriction at all. An unrestricted pass is finished for transfer the first time it is scanned. A three-day pass used on the Friday can still be handed on for the Saturday and Sunday. Naming the days does not narrow the pass so much as it splits it.
Withdrawing and refunding — for organizers
Two separate actions take a pass out of circulation, and the difference between them is entirely about the record they leave.
| Void | Revoke | |
|---|---|---|
| Records a reason | Yes, up to 120 characters | No |
| Records a refund reference | Yes, up to 120 characters | No |
| Timestamps the withdrawal | Yes | No |
| Cancels a pending transfer on that pass | Yes, automatically | No |
| Can restore the pass | Yes | Yes |
| Use it for | Refunds, canceled orders, anything you may be asked about later | Shutting a pass off quickly |
Void is the one to reach for when money was involved, because it is the only one that answers the question “why is this ticket dead?” six months later. It also tidies up after itself: if the holder had a claim code outstanding, voiding the pass kills the code in the same movement, so the recipient cannot claim a refunded ticket.
At the door, both look the same. The gate treats a voided and a revoked pass identically and turns the holder away.
Issuing passes in bulk
Passes are added to an event in batches. Each entry needs, at minimum, the identifier of the Mark that will carry it; everything else — tier, seat, named days, whether it is bound to a person — is optional and takes a sensible default. Every pass is created valid.
The response tells you three numbers: how many were added, how many were duplicates, and how many were invalid. This makes the operation safe to repeat. Uploading the same list twice does not create two sets of passes and does not fail — the second run reports every row as a duplicate and changes nothing. If a network problem leaves you unsure whether a batch went through, run it again rather than guessing.
Rows with no Mark identifier are counted as invalid and skipped without stopping the batch. If the numbers do not add up, look at the invalid count before looking anywhere else — a spreadsheet with a blank row in the middle is the usual explanation.
Running a gated event requires a plan that includes events. Without it, creating the event returns a refusal rather than an empty gate, so you will find out before the day rather than at the door.
Symptoms, causes and fixes
| Symptom | Cause | Fix |
|---|---|---|
| “Invalid or already-used code” | The code was claimed, canceled, or the pass was voided | Ask the sender to start a new transfer |
| “Ticket holder changed” | The pass moved to somebody else after the code was issued | The code is dead. Nothing to salvage |
| Transfer button does nothing | The pass is spent, withdrawn, or bound to a person | Check the pass status; person-bound passes never transfer |
| A second code was expected but the old one came back | Working as designed — one live code per pass | Cancel the first code if you want a genuinely new one |
| Passes were issued but the wallet is empty | They were issued against a different account, or the event is still a draft | Check the address the organizer used |
| The same pass appears twice after re-uploading a list | It does not — the duplicate was counted and discarded | Read the duplicate count in the response |
Things people commonly get wrong
Related reading: Pass types and validity, Operating the gate, Your passes in the App, and When something is not working.