Viator Reservation system APIs API
This section describes all the possible services, some of which are mandatory, that reservation systems can develop to integrate with Viator. All API requests made by Viator to the reservation system are specified. The reservation system will respond to Viator requests in a synchronous manner, responding as per specification. Both request and response formats are described in detail in subsequent sections of this document. ### Authentication These endpoints support two authentication mechanisms: the legacy body-embedded `ApiKey` field, which is always required in the request payload for v1 APIs, or the `X-Api-Key` header used by the v2 APIs. The header option was added so existing partners could migrate to header-based authentication without changing endpoints. ### BookingCutoff and Capacity elements The [Availability response](#tag/Reservation-system-APIs/operation/availability) includes two elements used to determine whether a booking can proceed: - **`BookingCutoff`** communicates the point in time after which a tour option may no longer be purchased. Exactly one of its three child elements must be provided: `DateTime` (a timezone-qualified timestamp), `ProductDateTime` (a timestamp in the product's own local time, with no timezone offset), or `NotApplicable` (a boolean, `true` if no cut-off exists for the product option). - **`Capacity`** communicates the remaining places available for Viator to book. Its `Simple` child element holds `Remaining` (the number of places left) and `ConsumedBy` (the age bands — `ADULT`, `CHILD`, `INFANT`, `YOUTH`, `SENIOR` — that draw down on those places), which lets specific age bands (e.g. infants) be excluded from consuming capacity. Both elements are part of the [Availability response schema](#tag/Reservation-system-APIs/operation/availability) — see that operation for the full field definitions.