Hand a waiting visit over

A visit ID (TypeID with the visit prefix).

Where the visit is. A visit usually goes expected → checked_in → checked_out, passing through awaiting_approval when a host must approve. A pre-registration that needs approval starts as awaiting_approval and, once the host approves, becomes expected with decision.outcome: approved. It can also end as denied, cancelled or no_show.

A visit type's key. Every organisation has six built-in visit types, meeting, interview, delivery, contractor, event and other, and can add its own in the console, such as parent_pickup or vendor. Each type has its own visit form, badge and rules. A key is lowercase letters, digits and underscores, starts with a letter and is at most 40 characters. It never changes, even when the type is renamed, and it's the same in live and test mode. List your organisation's types with GET /visit-types.

A key your organisation doesn't have returns validation_failed, and so does a type that is turned off when you create a visit or change a visit's type.

How the visit started: invitation (a host, the console or a secret key), pre_registration (the visitor, or a publishable key), walk_in (at the kiosk or front desk) or booking (an in-person booking).

A site ID (TypeID with the site prefix).

The gate the visitor came in through, once known.

The lead host. null while a visit for a team or for no one in particular hasn't been taken by anyone.

Who the visit is for: one person, several people (a lead host and others), a team, or desk (no one in particular, which your reception receives).

Everyone the visit is for, the lead first, and anyone reception asked to see the visitor, with their answer. Empty while nobody has taken a visit for a team or for no one in particular.

The team the visit is with: the one the visitor came to see, or the one receiving a visitor with no one in particular to see.

The person a walk-in asked for, when that person's visitors go through their office.

The visitor is waiting and nobody has taken the visit yet.

The visitor's details as stored on their visitor record.

The plate of the vehicle the visitor comes in, as given; the gate recognises it. Left out when there's none.

When the visitor is expected. null for walk-ins.

When the visitor's pass stops working. null for walk-ins.

The host's decision, for visits that needed approval.

The booking this visit came from, if any.

For a visit closed because the visitor was booked in for another time: what replaced it. null otherwise.

The visitor's QR pass: where and when it was last sent, and when and where it admits.

Answers to your organisation's custom fields, keyed by field key. The keys and allowed values come from the JSON Schema of the matching form (GET /forms). Keys that aren't in the form are rejected. Questions the form marks as required aren't enforced through the API; they're asked when the visitor checks in or completes their pre-registration. Answers to fields an admin marked sensitive or masked are never included for API keys or connected apps, nor in events and webhooks: they stay inside Agoo, seen only by the roles the admin chose.