# Online Check-in

To use this capability, add `octo/checkin` to your `Octo-Capabilities` header.

Some products require online check-in after booking confirmation and before the guest is allowed to use their tickets. This is typically the case when:

* The product has waivers that must be signed by each guest.
* The product has required questions that need answering (such as dietary requirements).
* The product is a multi-part package where each part needs a travel date and time chosen.

If the check-in process is skipped, the guest can still complete check-in on arrival, but it may delay entry.

All paths below are public `/octo` routes.

{% openapi src="<https://221588849-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M7bgGIyO7QYNOfUMfxh%2Fuploads%2Fgit-blob-fa2d8cb1d7297d352c2639e6c4c6a990f2add6d7%2Fopenapi.yaml?alt=media>" path="/checkin/lookup" method="post" %}
[openapi.yaml](https://221588849-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M7bgGIyO7QYNOfUMfxh%2Fuploads%2Fgit-blob-fa2d8cb1d7297d352c2639e6c4c6a990f2add6d7%2Fopenapi.yaml?alt=media)
{% endopenapi %}

**Request Body / Query Parameters**

Provide one of `email`, `mobile`, or `reference`.

* `reference` must be at least 3 characters unless it is a UUID.
* For email/mobile lookups, the first request (without `verification`) sends a 6-digit verification code and returns `verified: false`.
* For reference lookups, `verification` should be the guest name used for identity verification.
* If both `status` and `statuses` are sent, `status` is used.

**Response fields**

**Accepted `status` / `statuses` values (booking lookup)**

* `REDEEMED`
* `NO_SHOW`
* `ON_HOLD`
* `CANCELLED`
* `EXPIRED`
* `PENDING`
* `REJECTED`
* `REBOOKED`
* `QUOTE`
* `CONFIRMED`

If no booking matches, the API returns `400 Bad Request` (for example `BOOKING_NOT_FOUND`).

## Route Variants Using Nested `checkin`

After lookup, reuse the same verified check-in context on other endpoints by sending a nested `checkin` object.

For `GET` requests use query params like `checkin[email]=...`. For JSON request bodies use a top-level `checkin` object.

For gift-scoped lookups, `PENDING`, `REJECTED`, and `REBOOKED` are not valid status values.

### Endpoint coverage

* `GET /bookings/{uuid}`
* `GET /gifts/{uuid}`
* `GET /orders/{orderId}`
* `GET /products`

Base schemas are documented in [Bookings](https://docs.ventrata.com/octo-core/bookings), [Gift Vouchers](https://docs.ventrata.com/capabilities/gift-vouchers), [Multi-Booking Cart](https://docs.ventrata.com/capabilities/cart), and [Products](https://docs.ventrata.com/octo-core/products).

## Response Fields Added By This Capability

This capability augments serialized booking and order responses.

All booking fields from [Bookings](https://docs.ventrata.com/octo-core/bookings) are still returned, with the additional fields below.

### Order fields

When an order is serialized (for example with `octo/cart` endpoints), this capability adds check-in fields.

Nested `order.bookings[]` objects continue to include the booking fields above (`checkedIn`, `checkinAvailable`, `checkinUrl`). This capability does not add new check-in-specific fields to gift objects.

## Schema Additions (JSON)

These are additive fragments showing only fields introduced by this capability.

### `Booking`

```json
{
  "// ...rest of booking object": "...",
  "checkedIn": true,
  "checkinAvailable": true,
  "checkinUrl": "https://checkin.city-sightseeing.com/booking/89fe0192"
}
```