Run Check-In

Admission is recorded per person and per checkpoint. A CheckInSession is the checkpoint; a CheckIn is one successful admission at it. The same Participant can be admitted at a main gate and a meal counter independently, but not twice at one checkpoint.

• Checkpoint

  CheckInSession

  Organization-owned; may cover several Events

• Admission

  CheckIn

  One per Participant per session, enforced in the database

• Operating it needs

  checkin_sessions.operate

  At that session's Scope

• Credentials

  Participant QR, Account QR, LINK

  Static signed values, team members included

1. 1

   Decide what the checkpoint isCopy Anchor Link

   Each session is a distinct place or moment: the main gate, the Friday gate, a workshop room, the kit desk, a meal counter. Name it after the door staff will recognise, not after the ticket type. A session belongs to the Organization and can cover one or more Events.

2. 2

   Fill in the sessionCopy Anchor Link

   Field	Why it matters
   Covered Events	A Participant from any other Event is rejected
   Accepted Passes, or accept-all	The authoritative list here
   Open and close timestamps	Scans outside the window are refused
   Location	Shown to operators on the scan landing screen
   State: active, paused, closed	Paused and closed stop admission without deleting history

   The wizard asks for Events, then Passes, then an optional window, then a name and location. Instructions exist in the API and are displayed when set, but the app has no field for them. Afterwards, change the covered Events and accepted Passes on the session page.

   The accepted-Pass list is the part organizers get wrong. It is authoritative: a Pass not accepted here is rejected even when the person is fully valid, which is what a workshop-only checkpoint needs. Accepting all Passes is the right default for a main gate and usually wrong for a room.

3. 3

   Staff itCopy Anchor Link

   Operating a session requires checkin_sessions.operate at that scope. Any number of devices can scan the same session at once, because the once-per-person rule is enforced by the database rather than by the device. There is no per-device registration, revocation, or rate limit to manage.

4. 4

   Know which credential you are scanningCopy Anchor Link

   • Participant QR — a signed, static value per Participant. It can be printed or screenshotted, so the first successful scan wins.
   • Account QR — one per Account. The scanner lists the Participants this session accepts, then admits exactly one or asks the operator to choose.
   • LINK — a bearer URL rather than a QR value. Opening it renders the Participant's current credential and form.

   Credentials are derived from an identifier and a version, never stored, so a leaked database yields nothing usable. The version advances automatically when a Participant is claimed, removed, or transferred, or when their Registration switches; there is no organizer action to rotate one.

5. 5

   ScanCopy Anchor Link

   The launch scanner is a web app and needs connectivity for every acceptance. It offers camera scan, manual lookup by email, phone, or name, audible accept and reject cues, auto-advance, and a live connection state.

   Two things live elsewhere: live counts and recent scans are on the session page, and the scanner is bound to one session by its URL, so there is no session picker inside it.

   Admission has no undo. A CheckIn recorded at the wrong checkpoint cannot be removed in the app, so confirm the session before the doors open.

6. 6

   Read a duplicate correctlyCopy Anchor Link

   Diagram source

   sequenceDiagram
     participant S as Scanner
     participant A as Ulsav API
     participant D as Database
     S->>A: Submit credential for the session
     A->>A: Validate the session window and the credential signature
     A->>D: Write CheckIn, unique per Participant and session
     alt no earlier CheckIn
       D-->>A: CheckIn created
       A-->>S: Accepted
     else CheckIn already recorded
       D-->>A: Existing CheckIn
       A-->>S: Duplicate with original time and operator
     end

   One Participant may be admitted once per session, enforced in the database rather than by scanner memory: two devices scanning simultaneously resolve to exactly one CheckIn, and the loser sees the original time and the operator who recorded it.

   A duplicate is information, not an error: it usually means the person already entered. If the venue genuinely wants two admissions at one door, configure a second CheckInSession.

   A team check-in is a loop: each member has their own credential and gets their own CheckIn, and no member's admission implies another's.

7. 7

   Interpret a rejectionCopy Anchor Link

   Result	What to do
   Invalid QR	Re-present, then look the person up manually. Every attempt is recorded either way.
   Wrong Event, or Pass not accepted	Check the session's accepted-Pass list before overriding anything.
   Registration cancelled, Participant removed	Do not admit. A replacement never inherits the old person's attendance.
   Requirements pending	An approval is not approved, the Registration Form is unsubmitted, or a BEFORE_CHECKIN requirement is unmet. The Pass stays issued, admission stays blocked.
   Not open yet, paused, or closed	Fix the window or resume the session before reopening.
   Multiple matches	The search or Account resolution found several acceptable Participants; choose deliberately.

Wrong orientation and no connectivityCopy Anchor Link

The specification defines no orientation-specific behaviour. A credential is either decoded and validated or it is not: a rotated, blurred, or partly covered code fails to parse and is recorded as an invalid QR, like a damaged printout. Re-present it, or use manual lookup.

RelatedCopy Anchor Link

• Check-In — the model behind the session
• Registrations — requirements that block admission
• Event status — what a cancelled Event does to admission