githubEdit

Online Check-in

Just like with an airline, except for tours and activities

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.

Check-in Lookup With identityId

post

Adds identity-based matching support to check-in lookup.

Body
emailstringOptional

Email value.

Example: [email protected]
mobilestringOptional

Mobile value.

Example: +12025550123
referencestringOptional

Reference value.

Example: REF-2026-001
verificationstringOptional

Verification value.

Example: VERIFIED
statusstringOptional

Current status value.

Example: CONFIRMED
statusesstring[]Optional

List of status values to filter by.

Example: ["CONFIRMED","ON_HOLD"]
countrystringOptional

Country value.

Example: US
identityIdstringOptional

From capabilities octo/checkin, octo/identities.

Example: identity_customer_001
Responses
chevron-right
200

Returns the standard check-in lookup response.

application/json
post
/checkin/lookup

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, Gift Vouchers, Multi-Booking Cart, and Products.

Response Fields Added By This Capability

This capability augments serialized booking and order responses.

All booking fields from 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

Last updated