Invite a guest and track plus-ones
Spend your comp allocation: invite guests, send claim links, and keep plus-ones honest.
Owned by Host / Promoter · 13 steps · about 20 minutes
Why this exists
Your comps live in a bucket: a named allocation on your event with a hard cap, a tier, and a default plus-one count. The venue creates and sizes that bucket — you cannot create one, resize one, or move allocation between them. That is the whole point of an allocation, and it is why bucket creation is staff-only while inviting into your own bucket is yours.
The number that surprises people is how allocation is counted: consumed = 1 + the plus-ones you allowed, summed over every live entry, and it is counted the moment you invite, not when the guest turns up. Invite ten people with two plus-ones each out of a bucket of ten and you are refused on the fourth. Revoking or letting an entry expire gives the allocation back.
A comp is not a name on a clipboard. When it is claimed, the platform mints a real ticket at zero face value through the normal payments path — its own $0 paid order, zero ledger postings — and a real door pass with the zones of the bucket's tier. That means comps consume real inventory: a sold-out tier makes a comp fail with an inventory error, exactly as it would for a paying customer. It also means comp tickets are never resalable, by design.
The claim link is a token and the token is the credential: your guest needs no account to claim, name their plus-ones, and walk in.
Before you start
- A comp bucket on your event with you as its owner (the venue creates it).
- Enough remaining allocation for the guest plus the plus-ones you intend to allow.
- A tier with inventory left — comps consume real inventory.
Practise with
| Persona | Password | Note | |
|---|---|---|---|
| host_promoter | promoter@demo.club | promoter123 | scoped host on demo-event-0001, owns the 'Promoter X' bucket (allocation 10, one plus-one by default) |
| venue_manager | manager@club.test | manager123 | creates and sizes the buckets |
| door_staff | door@club.test | door123 | checks your guests in on the night |
Steps 1 — Venue Manager
their manual →Creates and sizes your comp bucket — how many comps you get is the venue's decision.
-
1Create the promoter's bucket: a name, owner type promoter, the host as owner, a tier, a total allocation and a default plus-one count.Expected result 201 with the bucket, its allocation and its consumed and remaining counts.Watch out for The tier you pick decides the door zones the comp pass will open, so a guest-list ticket on a general admission tier does not open the VIP room. Admin and venue manager only — the host cannot create or resize their own bucket.
Steps 2–5 — Host / Promoter
their manual →-
2Open the guest list dashboard for your event.Expected result Your buckets with allocation, consumed, remaining and a status breakdown, plus an entries table and an audit tab.Watch out for You see only the buckets you own. The venue's house buckets and the artist list are on the same event and invisible to you, so 'remaining' on your screen is your allowance, not the room's.
-
3Read the same allocation figures as JSON before a big invite run.Expected result Consumed and remaining per bucket, recomputed live.Watch out for Remaining comes back as null for the venue's door-override bucket, because overrides are exempt from allocation. You will not see that bucket anyway.
-
4Invite a guest from your bucket: name, email, and how many plus-ones they may bring. On the dashboard that is the + Invite Guest form on the bucket.Expected result 201 with the entry in status invited, a claim token, and an invite email recorded to the guest.Watch out for 409 allocation_exceeded counts the plus-one allowance, not the plus-ones actually named — one guest with three plus-ones spends four. Also 409 duplicate_guest (one live entry per email per event, across all buckets), and 409 bucket_frozen or bucket_closed. Sending allow_duplicate deliberately overrides the duplicate guard and is audited with your name on it.
-
5Send the invite. Use Copy claim link on the entry if you would rather send it yourself over a direct message than rely on the email.Expected result A /guestlist/claim/ link carrying the entry's token.Watch out for That link is the credential. Anyone holding it can claim the comp, so do not post it publicly. If it leaks, revoke the entry and re-invite — a resend rotates the token.
Steps 6–7 — Customer (Guest)
their manual →Claims the invite from a tokenised link and names their own plus-ones, with no account.
-
6As the guest, open the claim link. No account, no password.Expected result A styled claim page naming the event, the host and the plus-ones allowed.Watch out for 404 for an unknown token, 410 when the invite expired or was revoked, and 423 when the bucket has been frozen. Claiming closes at the bucket's cutoff, which defaults to the event's doors-open time — a link that worked yesterday can be dead at 9pm.
-
7Claim it, and name your plus-ones while you are there.Expected result A zero-value ticket and a door pass, with a pass serial returned. Named plus-ones each get their own ticket and pass.Watch out for 409 plus_one_limit if you name more than you were allowed. If you have no member account the platform creates a shadow user row for you so the ticket and pass have an owner — it grants you no groups and no login. Members who claim can see the comp afterwards on their comps page.
Steps 8–10 — Host / Promoter
their manual →-
8Track the list as it moves: invited, claimed, ticketed, checked in — plus revoked and expired.Expected result Your entries only, filtered to the buckets you own, with plus-one counts.Watch out for Entries expire quietly at the claim cutoff and hand their allocation back. If your list looks smaller than you remember, check for expired rows before you blame the system.
-
9Chase a guest who never claimed: resend the invite, rotating the token by default.Expected result A fresh claim link and a new invite email.Watch out for Resend is also the only way to revive an expired entry — and the allocation is re-checked when you do, so a full bucket will refuse the revival. Rotating the token kills the old link immediately, which is the right move after a leak.
-
10Take a comp back when plans change. Give a reason.Expected result The entry, its plus-ones, their tickets and their passes are all revoked together, and the tier inventory is returned.Watch out for You cannot revoke a guest who has already walked in: that needs an admin with force, and you get 403 'hosts cannot revoke checked-in guests'. Revocation is a cascade, so a guest with three plus-ones loses four passes, not one.
Steps 11–12 — Door Staff
their manual →Finds the name on the night and counts the plus-ones in.
-
11On the night, open the guest list surface from the scanner and search for the name.Expected result Matching entries with their bucket, plus-one allowance and whether they are already in.Watch out for Search by the name on the list, not the name on the ID — the promoter invited whoever they invited.
-
12Check the guest in, and check their plus-ones in with them.Expected result The entry flips to checked in and the plus-one count comes down.Watch out for 409 already_checked_in is the anti-passback guard doing its job, not a broken list. A check-in runs the real access pipeline underneath, so a revoked or refunded credential is refused with the scanner's own reason code even here.
Steps 13 — Host / Promoter
their manual →-
13After the night, come back and read the audit tab for your buckets.Expected result Every invite, resend, claim, revoke, expiry and check-in with its actor and timestamp.Watch out for That log is append-only — it cannot be edited or deleted by anyone, including admins. It is what settles the 'we had more people on the list than that' conversation.