Signing a visitor in and out

A sign-in through the API is not a second-class visit. It goes through the same pipeline as a kiosk sign-in: the host is notified by email, SMS, Teams or Slack, the badge is printed if the visit type prints one, the confirmation email goes out and every integration and webhook fires.

1. Pick the visit type

If you leave visit_type out, the location’s default visit type is used. That is fine for a single-flow reception. If you have several — “Visitor”, “Contractor”, “Delivery” — fetch them once and cache the ids:

curl -G https://api.vizito.eu/api/companies/{company_id}/visittypes \
  -H "Authorization: Bearer $VIZITO_API_KEY" \
  -d active=true

2. Find out which fields it asks for

The questions a visitor answers are configured per visit type. GET /api/companies/{company_id}/fields returns them all, merged across visit types:

[
  { "field_name": "first_name", "field_description": "First name", "field_content_type": "text", "field_status": "required" },
  { "field_name": "company", "field_description": "Company", "field_content_type": "text", "field_status": "optional" },
  { "field_name": "badgenumber", "field_description": "Badge number", "field_content_type": "number", "field_status": "optional" }
]

A field’s field_name is the key you send. Custom fields are no different from built-in ones — they are just extra keys in the body.

The API does not enforce field_status: "required". A visit created through the API with a required field missing is accepted, and shows up in the Backoffice with that column empty. Validate on your side if it matters to you.

3. Create the visit

cURL

curl -X POST https://api.vizito.eu/api/visitors \
  -H "Authorization: Bearer $VIZITO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "company_id": "5f2a1b9c4d3e2f0011223344",
    "visit_type": "5f2a1b9c4d3e2f0011223399",
    "first_name": "Ada",
    "last_name": "Lovelace",
    "company": "Analytical Engines Ltd",
    "email": "ada@example.com",
    "phone": "+32470123456",
    "recipient": "Jane Doe",
    "recipient_mail": "jane.doe@example.com",
    "badgenumber": "A-1183",
    "signed_in_source": "0"
  }'

Response

{
  "message": "Visitor added!",
  "data": {
    "_id": "66b0f1a2c3d4e5f600112233",
    "first_name": "Ada",
    "signed_in": "2026-08-29T07:58:11.000Z",
    "signed_in_source": 0,
    "visit_type": "5f2a1b9c4d3e2f0011223399"
  }
}

Keep data._id — it is the visitor id you need to sign them out again.

Set signed_in_source to "0" so the visit is recorded as a Backoffice/API sign-in rather than a kiosk one. It shows up as such in the Backoffice and in exports.

Notifying the right host

recipient is the host’s name as it should appear on the badge and in the notification. recipient_mail is where the notification goes. If you send a recipient that matches a host you already maintain in Vizito, use that host’s exact cn so reporting per host stays clean. Send signed_in_frombo with an ISO 8601 timestamp to record a visit that happened earlier — useful when you are importing from another system:

{ "company_id": "...", "first_name": "Ada", "signed_in_frombo": "2026-08-28T14:03:00.000Z" }

4. Sign them out

curl -X PUT https://api.vizito.eu/api/visitors/66b0f1a2c3d4e5f600112233 \
  -H "Authorization: Bearer $VIZITO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "company_id": "5f2a1b9c4d3e2f0011223344", "signed_out_source": "0" }'

Leave signed_out out and the visitor is signed out now; send an ISO 8601 timestamp to record a departure that already happened. To close several visits at once — an evacuation, an end-of-day sweep — use the bulk endpoint:

curl -X POST https://api.vizito.eu/api/companies/{company_id}/visitors/signout \
  -H "Authorization: Bearer $VIZITO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "ids": ["66b0f1a2c3d4e5f600112233", "66b0f1a2c3d4e5f600112244"] }'

It answers per id, so you can see exactly which ones were already signed out:

[
  { "id": "66b0f1a2c3d4e5f600112233", "status": "success", "message": "Visitor signed out" },
  { "id": "66b0f1a2c3d4e5f600112244", "status": "skipped", "reason": "Visitor not found or already signed out" }
]

5. See who is still inside

curl https://api.vizito.eu/api/visitors/signed_current/{company_id} \
  -H "Authorization: Bearer $VIZITO_API_KEY"

Returns the full list of visitors that are signed in and not signed out, respecting the location’s multi-day sign-out interval. This is the list an evacuation report should be built on.

All visitor endpoints

Filtering, updating, anonymising and exporting visits.

Get started

Guides

Signing a visitor in and out

1. Pick the visit type

2. Find out which fields it asks for

3. Create the visit

Notifying the right host

4. Sign them out

5. See who is still inside

All visitor endpoints

​1. Pick the visit type

​2. Find out which fields it asks for

​3. Create the visit

​Notifying the right host

​Backdating a sign-in

​4. Sign them out

​5. See who is still inside

All visitor endpoints

1. Pick the visit type

2. Find out which fields it asks for

3. Create the visit

Notifying the right host

Backdating a sign-in

4. Sign them out

5. See who is still inside