Check in a guest from the list

Search the guest list, check in an entry and its plus-ones, and issue a ticket on the spot.

Owned by Door Staff · 10 steps · about 14 minutes

Why this exists

A comp is a real ticket. When a promoter's guest claims their invite the platform mints a genuine zero-value ticket on a zero-value paid order, and issues a genuine door pass from it. That is why guest-list check-in is not a separate honour system: the person on the list has a credential just like a paying customer, and this screen exists for the case where they have not got it on their phone.

The important design decision is that manual check-in still runs the real scan pipeline. Pressing Check In does not write a check-in flag; it validates the guest's pass through exactly the gate chain behind the scan endpoint, and only then records a green scan through a bookkeeping reader named Guestlist Manual Check-in. That means anti-passback, revocation, resale suspension and refunds all still apply here — you cannot route around a red scan by searching the name instead.

Exactly two refusals are waived, because a door check-in is a deliberate act by a member of staff. The first is the doors-open time window: staff legitimately work the list before doors, so a not-yet-open event does not block you. The second is wrong zone, because the manual reader is a bookkeeping reader in zone A rather than a real turnstile. Everything else about the guest's right to enter is not overridable and comes back as a refusal carrying the scanner's own reason code — a cancelled or completed event, a revoked or resold or suspended pass, a revoked ticket, or a refunded order.

Plus-ones are the other half of the screen and they are an allowance, not a suggestion. Each named plus-one is its own row with its own ticket and its own check-in button. Admitting more people than the promoter was allocated is what makes the whole allocation system meaningless by the third event.

Before you start

  • An employee session (door staff, venue manager or admin).
  • An event in announced, on_sale, sold_out or in_progress — draft events never appear in the picker.
  • A guest list with entries. The seed ships Promoter X and Artist Guest List buckets on demo-event-0001.

Practise with

PersonaEmailPasswordNote
door_staffdoor@club.test door123door shift account: scanner + guest list, nothing else
venue_managermanager@club.test manager123shift lead: implies door_staff, plus intake, sales, guest list, marketing
host_promoterpromoter@demo.club promoter123scoped host on demo-event-0001; owns the seeded Promoter X comp bucket

Steps 1–7 — Door Staff

their manual →
  1. 1
    Open the guest-list door screen and select tonight's event from the dropdown. The page reloads with the list bound to that event.
    /scanner/guestlist guestlist
    Expected result The event name, its status, and an override counter reading used / cap.
    Watch out for Selecting the event is not optional — the search endpoint is scoped per event, and an unselected page has nothing to search.
  2. 2
    Type at least two characters of the guest's name or email into the search box. Results appear as you type, capped at twenty-five rows.
    /api/guestlist/door/{event_id}/search guestlist
    Expected result Matching entries with their bucket, status, plus-one allowance and a set of action buttons.
    Watch out for One character does nothing at all — the endpoint requires two. Search by the name the promoter put on the list, not the name on the ID; comps are listed by whoever invited them.
  3. 3
    Read the buttons on the row before pressing anything. Check In appears when the entry already has a ticket. Issue and Check In appears when it does not — the entry was invited or claimed but never ticketed. Reinstate and Check In appears on an expired entry, and is manager-only.
    Expected result Exactly the buttons that apply to that row's state, and no others.
    Watch out for If a row you expected shows no button at all, it is usually already checked in or revoked. Read the status chip rather than clicking twice.
  4. 4
    Press Check In for a ticketed guest.
    /api/guestlist/door/{event_id}/entries/{entry_id}/checkin POST guestlist
    Expected result The row flips to checked in, and a green scan row is written through the manual check-in reader.
    Watch out for A second press comes back 409 already_checked_in. That is anti-passback reaching you through this screen too — the same guard the scanner uses, not a separate one.
  5. 5
    Check the plus-ones in individually using their own named buttons — one per named guest — as they actually arrive.
    /api/guestlist/door/{event_id}/entries/{entry_id}/checkin POST guestlist
    Expected result Each named plus-one flips to checked in separately.
    Watch out for Plus-ones arriving separately from their host is normal. Do not check them all in at once to save time; the counts are what the promoter's next allocation is based on.
  6. 6
    For a guest on the list who never claimed their invite, press Issue and Check In. This mints the comp ticket, issues its pass and checks them in as one transaction.
    /api/guestlist/door/{event_id}/entries/{entry_id}/issue-and-checkin POST guestlist
    Expected result A ticket, a pass and a check-in, all in one go.
    Watch out for Comp inventory is real. If the tier is sold out this refuses with 409 insufficient_inventory — a guest list does not conjure capacity, it spends it.
  7. 7
    Learn the refusals that are NOT overridable here, so you escalate instead of retrying: a cancelled or completed event, a revoked or resold pass, a pass suspended because the ticket is listed for resale, a revoked ticket, and a refunded order. Each comes back with the scanner's own reason code and writes no green row.
    Expected result A 409 carrying a familiar reason code rather than a check-in.
    Watch out for Two refusals ARE waived on purpose and will surprise you the other way: the doors-open window, and wrong zone. So yes, you can legitimately work the list an hour before doors.

Steps 8–9 — Venue Manager

their manual →

Allocated the list you are working, and is the only one who can revive an expired invite at the door.

  1. 8
    When the door hits an expired invite, come over and use Reinstate and Check In yourself — reviving an expired entry needs venue_manager or above.
    /api/guestlist/door/{event_id}/entries/{entry_id}/issue-and-checkin POST guestlist
    Expected result The entry revives, tickets and checks in.
    Watch out for Revival re-checks the bucket's allocation. If the bucket is full it refuses, and the honest answer is a walk-in override against the house bucket instead.
  2. 9
    Watch the same list from the event dashboard during the shift, where the entries tab shows live statuses and the audit tab shows every action with who did it.
    /admin/guestlist/{event_id} guestlist
    Expected result Buckets with consumed and remaining counts, entries with statuses, and an append-only audit log.
    Watch out for The audit log cannot be edited or deleted by anyone, admins included — database triggers abort the attempt. Treat it as the record of the night, because that is exactly what it is.

Steps 10 — Admin

their manual →

Holds the escalations the door cannot resolve — a revoked comp, a cancelled event, a settings change.

  1. 10
    If a check-in is disputed after the fact, pull the raw audit tail for the event filtered by action.
    /debug/guestlist/audit/{event_id} guestlist
    Expected result Rows for manual_checkin, door_override, entry_revoke and the rest, with actor and timestamp.
    Watch out for Guest token actions have no actor user id — they carry the entry token id instead. A blank actor is a guest acting on their own claim link, not a missing record.