What the visitor badge API answers

Every verdict the verify, check-in and check-out calls can return, every action they can record, and the one place the three deliberately disagree — a visitor who checked out and came back.

Updated 30 Aug 2026

The three gate calls — verify, check-in and check-out — all take a scanned code and answer in the same shape. This is that shape: the verdict your barrier acts on, and what Offision recorded while answering. The task that uses them is Open your gates with an Offision visitor badge.

The verdict

`verify`	What it means
`valid`	Good now, at this building
`notYetValid`	A real badge, but the visit has not started
`expired`	The visit has passed
`cancelled`	The visit or the badge was cancelled — or the badge is still waiting for a code from your own system
`rejected`	An approver turned this visitor down
`waitingForApproval`	Nobody has approved this visitor yet
`wrongLocation`	A real, live badge — for a different building
`alreadyCheckedOut`	This visitor has already left
`notFound`	The code matches nothing

Alongside it comes isGranted, which is the field your barrier actually acts on, and the visitor and badge behind the code, so the screen beside the gate can show a name rather than a code.

What was recorded

Check-in and check-out return action alongside the verdict, saying what was actually written.

`action`	When you get it
`checkedIn`	First arrival — the badge moves to Visiting
`alreadyCheckedIn`	The visitor was already inside. Nothing was written
`reCheckedIn`	They had checked out and came back. The check-out was cleared
`checkedOut`	The badge moves to Left
`alreadyCheckedOut`	Already recorded. The departure time was left alone
`none`	Nothing was recorded — a refused scan, a long term badge, or someone leaving who never checked in

Re-entry, checking out and long term badges

Two behaviours worth knowing before you write the gate logic:

Leaving is more permissive than arriving. Check-out accepts any badge it can resolve, expired ones included, so nobody is held inside a building because their pass lapsed during a meeting. The departure is recorded for anyone who actually checked in; for anyone who did not, the gate still opens and action comes back as none rather than inventing a visit.
Coming back after checking out re-admits, provided the visit covers that building. Verify reports alreadyCheckedOut and refuses; check-in on the same code re-opens the visit. That is the one place where the two calls deliberately disagree, and it is why a gate should call check-in rather than acting on verify’s answer itself.

A long term badge has no visit to open, so action is always none for one — a valid one still opens the gate, which is the point of it. Those carry their own endpoints.