Skip to content

Re-entry and check-out

By default, a guest who checks in stays inside the event until the end of the night. If your event allows re-entry, you can turn on check-out so the system records when a guest leaves, and a later scan lets them back in. This page is the complete reference for the re-entry lifecycle.

Check-out is the act of recording that a guest has left the event. After check-out, the guest’s ticket flips to a “checked out” state, and the guest can be checked in again with a fresh scan.

Check-out only matters when your event allows guests to come and go (for example: a multi-day fair, a venue with food stalls outside, a guest who needs to grab something from their car). For a single-entry event, you leave check-out off — the ticket locks at the first check-in.

To stop guests from being checked out at the wrong moment (for example: a mis-scan right after walking in), the system uses a per-guest sliding window. The window does not sit at a fixed clock time — instead, for each guest it starts at that guest’s check-in time and stays open for check_out_window_minutes. So a guest who checks in at 19:00 with a 30-minute window can be checked out from 19:00 to 19:30; a guest who checks in at 20:30 with the same window can be checked out from 20:30 to 21:00.

When you turn check-out on, you choose how long this sliding window is. The options are:

Window length Best for
15 minutes Short events, or guests who typically leave again very soon after arriving.
30 minutes Default for most events — covers guests who step out and come back within half an hour.
60 minutes Longer events where guests may go in and out (food runs, trips to the car) within an hour of arriving.
90 minutes Fairs, multi-area events, guests who come and go over a longer stretch after each check-in.
120 minutes All-day events where guests move freely in and out for up to two hours after each check-in.

The system will not let you pick a window longer than a single event day’s running time, because the sliding window starts at each guest’s check-in time and must fit inside the same event day. For example: if your day runs for 60 minutes, you cannot set a 90- or 120-minute check-out window — a guest who checks in near the end of the day would have a check-out window that runs past the day’s closing time.

When you try to pick a value that is too long:

  • The list of options automatically hides the values that do not fit.
  • If a schedule change makes the current value invalid, the system switches to a safe value (usually about half the day’s length).
  • An error message appears if no value fits at all — you need to extend the event day’s hours first.

A guest can be checked out in one of two ways.

1. Scanning the QR code on the way out (exit door)

Section titled “1. Scanning the QR code on the way out (exit door)”

If you have a scanner at the exit, staff simply scan the guest’s QR code again. The system records that the guest has left right away — the scanner screen turns green (“Check-out success”). This is the clearest, most controlled path — you know exactly when the guest left and through which door.

When check-out is enabled for the event, scanning a guest who is already inside (for example: they stepped out and are coming back) automatically checks that guest out first. The scanner screen turns blue (“Auto checked out (re-entry)”) to signal “checked out.” At this point the guest is in the “out” state. This blue path is the re-entry rescan — distinct from the deliberate exit-door scan, which is green.

After a guest has been checked out, their next scan checks them back in — the system creates a new check-in. The full lifecycle (via the re-entry rescan path) is therefore:

  1. Scan 1: The guest is checked in for the first time (green).
  2. Scan 2 (re-entry rescan, as the guest is coming back in): The system auto-checks the guest out first (blue).
  3. Scan 3 (next scan, the guest comes back in): The guest is checked in again (green).

Note that Scan 2 is blue only because it is the automatic re-entry rescan. A deliberate exit-door scan instead shows green (“Check-out success”). See the scan states reference for the full color matrix.

This can repeat many times during an event, as long as check-out stays on and the guest scans within the allowed window.

On walk-in companion events, companions ride on the primary guest’s ticket — so check-in, check-out, and re-entry apply to the whole party, not to individual companions:

  • A scan admits the primary and their companions together; a re-scan of a fully admitted party reports the party total.
  • Checking the primary out checks the party out; the next scan admits everyone again.
  • Undoing the primary’s check-in clears the whole party (see Manual check-in/out and undo).

On own-ticket events, every companion holds their own QR code and checks in and out individually, like any other guest.

Sometimes the system refuses a check-out action (both manual scans and automatic ones). There are three main reasons:

Block reason Meaning What to do
Check-out is not enabled for the event The organizer has not allowed re-entry. No check-out is possible; the guest can only stay inside, or contact the organizer.
Check-out window is not open yet The current time is earlier than the configured check-out window (for example: the window is the final 30 minutes, but the event is only halfway through). Wait until the window opens. If a guest must leave urgently, the organizer can use the manual check-out action from the dashboard.
Today is not an active day The event spans multiple days and today is turned off in the schedule. Check the schedule with the organizer.

Besides scanning at the door, the organizer can manually check out a guest directly from the event dashboard (in the manage check-ins section). This action bypasses the check-out window — useful when you need to handle a special case (for example: a guest has an emergency and must leave early). Only organizers have this permission; door staff cannot do it.