Revoke a comp

Pull a name off the list, kill its pass, and give the capacity back.

Owned by Venue Manager · 7 steps · about 8 minutes

Why this exists

Revoking a comp is a cascade, not a delete, and the cascade is the point. One action marks the entry revoked, revokes every named plus-one under it, marks the underlying tickets revoked, revokes their door passes through the access module, and returns the tier inventory. Any one of those left undone would produce a familiar failure: a name off the list who still scans green, or capacity the venue has silently lost.

The pass revocation is terminal. A revoked credential is blacklisted by serial and by payload hash and its time-code secret is killed, so it fails loudly at the door with Pass Revoked rather than quietly not working. If you revoke the wrong guest, the fix is to invite them again — a new entry, a new ticket, a new pass — not to undo anything.

The one deliberate speed bump is a guest who has already walked in. Revoking a checked-in entry refuses with already_checked_in unless an admin forces it. That is not squeamishness: someone is physically in the building, and a system that lets a list edit quietly contradict the door count is a system whose numbers you cannot use.

Before you start

  • A venue manager or admin session.
  • A live entry on a bucket for the event.

Practise with

PersonaEmailPasswordNote
venue_managermanager@club.test manager123shift lead: implies door_staff, plus intake, sales, guest list, marketing
adminadmin@club.test admin123the only account that can touch money, identity and contracts
door_staffdoor@club.test door123door shift account: scanner + guest list, nothing else

Steps 1–5 — Venue Manager

their manual →
  1. 1
    Find the entry in the Entries table and check its status chip before acting: invited, claimed, ticketed, checked in, revoked or expired.
    /admin/guestlist/{event_id} guestlist
    Expected result The entry with its bucket, plus-ones and status.
    Watch out for An expired entry does not need revoking — it has already released its allocation. Revoking it just adds noise to the audit log.
  2. 2
    Press Revoke and give a reason. This cascades to the plus-ones, the tickets and the passes, and returns the inventory.
    /api/guestlist/entries/{entry_id}/revoke POST guestlist
    Expected result The entry and its plus-ones flip to revoked; the bucket's remaining figure rises again.
    Watch out for 409 already_checked_in means the guest is inside. Only an admin can force past that, and they should have a reason better than tidiness.
  3. 3
    Confirm the allocation actually came back by re-reading the bucket's consumed and remaining figures.
    /api/guestlist/events/{event_id}/buckets guestlist
    Expected result Consumed down by one plus the revoked entry's plus-one allowance.
    Watch out for It drops by the ALLOWANCE, not by the number of named plus-ones — the same asymmetry that governed the allocation on the way in.
  4. 4
    If you revoked in error, do not go looking for an undo. Invite the guest again as a fresh entry.
    /admin/guestlist/{event_id} guestlist
    Expected result A new entry, a new claim link, and eventually a new pass.
    Watch out for The old pass stays dead forever. Revocation is terminal by design, and re-issuing on the same ticket is refused with 409 pass_revoked rather than minting a serial the blacklist would not cover.
  5. 5
    For the softer case — a guest who let their invite expire — use Resend with a rotated token instead of revoking anything. This is the only way to revive an expired entry.
    /api/guestlist/entries/{entry_id}/resend POST guestlist
    Expected result A fresh claim link and the entry back in play.
    Watch out for Resend re-checks the allocation. If the bucket filled up while they were slow, the revival is refused — which is the correct answer, not a bug.

Steps 6 — Door Staff

their manual →

Meets the consequence at the door if the revocation lands after the guest arrives.

  1. 6
    On the night, expect a revoked guest to scan red with Pass Revoked. Read it out and send them to a manager; do not re-scan hopefully.
    /scanner access
    Expected result A red panel reading Pass Revoked.
    Watch out for If the device has been offline since before the revocation, its cached bundle may not know. This is exactly what the live push feed exists to prevent — and why a manager-grade session on the door device matters.

Steps 7 — Admin

their manual →

Is the only role that can force a revocation on a guest who is already inside.

  1. 7
    As an admin, force a revocation on a checked-in guest when it is genuinely necessary — an ejection, say.
    /api/guestlist/entries/{entry_id}/revoke POST guestlist
    Expected result The revocation completes despite the check-in.
    Watch out for The check-in row is not deleted. The night's door count still says they came in, because they did — the audit log is a history, not a current-state summary.