# 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="/files/9aBZzqykFPaTU7bfbNrr" 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](/octo-core/bookings.md), [Gift Vouchers](/capabilities/gift-vouchers.md), [Multi-Booking Cart](/capabilities/cart.md), and [Products](/octo-core/products.md).

## Response Fields Added By This Capability

This capability augments serialized booking and order responses.

All booking fields from [Bookings](/octo-core/bookings.md) 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"
}
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.ventrata.com/capabilities/online-check-in.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.