Integration reference
What is implemented, and against whose specification.
This page describes the endpoint surface built for each sales channel, how products are identified, how calls are authenticated, and how errors and changes are handled.
Last updated 24 October 2026. Certification status is shown per channel below.
Scope
GetYourGuide
The six mandatory endpoints.
Certified by GetYourGuide on 20 October 2026 (Supplier API live test passed); first supplier connected through self-mapping on 21 October 2026. Last checked 2026-10-24.
| Endpoint | Direction | What it does |
|---|---|---|
| Availability | GetYourGuide calls RezRoute | Asks whether a product has seats on a date, or across a range of dates. Answered from the live calendar held by the marketplace that owns the product. Nothing is served from a copy. |
| Reservation | GetYourGuide calls RezRoute | Holds seats while a traveller completes payment. The specification sets sixty minutes as the desired hold window and fifteen minutes as the minimum. |
| Reservation cancellation | GetYourGuide calls RezRoute | Releases a hold that was not converted into a booking, returning the seats to the calendar. |
| Booking | GetYourGuide calls RezRoute | Converts a hold into a confirmed booking. The seat check and the write happen inside one database transaction in the marketplace that owns the product, which is why two channels cannot sell the same seat. |
| Booking cancellation | GetYourGuide calls RezRoute | Cancels a confirmed booking and returns the seats to the calendar. |
| Availability update notification | RezRoute calls GetYourGuide | Reports that availability for a product has changed. This endpoint is hosted by GetYourGuide, so it is the one call in the set that travels outward. |
Certification runs in three phases: initial self-testing, advanced self-testing, and then live testing with the GetYourGuide Connectivity team. The Supplier API live test passed, and GetYourGuide certified this connection on 20 October 2026. The first supplier was connected through self-mapping on 21 October 2026. The channel status on this site moves only when a phase is genuinely complete, and it is rendered from one place in the codebase so that it cannot say one thing here and another on the channels page.
Viator
The mandatory API set.
Not started. Viator requires five active engaged operators before development may begin. Last checked 2026-08-28.
Development against Viator has not started, and the reason is a Viator rule rather than a scheduling choice: Viator requires that a reservation system already has registered operators using it, with a published Connectivity Quality Program minimum of five active engaged operators, before development may commence. The surface below is what will be built when that condition is met.
- Tour List
- Calendar v2.0
- Availability Check v2.0
- Event Notifications v2.0
- Special Offer Notifications
- Special Offers
- Reserve v2.0
- Booking
- Booking Cancellation
| Window ahead of today | Calendar refresh |
|---|---|
| 0 to 2 days ahead | Every 2 hours |
| 3 to 30 days ahead | Every 1.5 days |
| 90 days ahead | Every 3 days |
| 180 days ahead | Every 4.5 days |
| Beyond 180 days | Every 7 days |
OCTO
The OCTO supplier endpoint, certified.
This service also operates an OCTO supplier endpoint at https://api.rezroute.com/octo/1. Supplier Certification passed on , certificate 25e171d6-d076-4c47-814f-e5405a219067, verify.
Reseller Certification covers the OCTO client used on the marketplace side, certificate b5ac78db-3c1a-4ae1-8b89-fc55c1421be8, verify.
A sales channel, GetYourGuide, has been routed through this host since 19 September 2026, and the live connection of 21 October 2026 runs through it. The statuses on the channels page are unchanged by the OCTO certification. Full certification detail.
Identifiers
How a call finds the right calendar.
- Supplier identifier
- GetYourGuide requires one stable Supplier ID per operator. An operator therefore has a single identity on the channel regardless of how many products are listed, and that identifier does not change if products are added, retired or re-priced.
- Product identifier
- Every product identifier resolves to exactly one marketplace and one product inside it. That resolution is the routing decision, and it is the only decision this service makes.
- Stability
- An identifier is never reused for a different product. When a product is retired its identifier retires with it, so a stale reference fails cleanly instead of quietly selling something else.
- Mapping on request
- GetYourGuide requires that mapping information is supplied to any supplier who asks for it, within two business days. Operators do not need to hold or manage these identifiers themselves, but they are entitled to see them.
Authentication
HTTP Basic, in both directions.
The GetYourGuide Supplier API specification requires HTTP Basic authentication in both directions and does not accept OAuth or bearer tokens. A connectivity partner implements what the channel accepts, so that is what is implemented: a credential for the channel calling this service, and a separate credential for this service calling the channel.
Basic sends a reusable credential on every request, so the controls around the credential carry the weight. Those controls, along with transport encryption, logging redaction and rotation, are set out on the security page.
Errors
Every response is a 200.
Under the GetYourGuide Supplier API specification, every response is returned with HTTP status 200 and any error is carried inside the JSON payload. A refusal, a validation failure and a successful booking all arrive with the same transport status.
That has one consequence a reviewer should check for, so it is stated here: the transport status cannot be used as a health signal. Monitoring reads the payload, and an error carried in a payload is counted against the error ceilings published on the reliability page. A service that counted only non-200 responses would report a perfect month while failing every booking in it.
Versioning
Breaking changes, and the notice given before them.
There is no public API here, so there is no public version number for a third party to pin. Versions belong to the specifications implemented: the GetYourGuide Supplier API, and the Viator API versions named above. When a channel revises its specification, the work to follow it is recorded as an ordinary change.
A change is treated as affecting connectivity if it alters what a channel receives, how a product is identified, or how a call is authenticated. Anything in that category is announced before it happens, not after.
- GetYourGuide receives at least 30 days notice of any change affecting connectivity. That is a requirement of the specification and it is met as written.
- Every such notice appears on the changelog on the day it is given, carrying the date the change takes effect.
Sources
The specifications this is built against.
Each channel publishes its own documentation, and that document is the authority. Where this page and a channel specification disagree, the specification is right and this page is stale.
- GetYourGuide Supplier API specification, published by GetYourGuide.
- Viator reservation system API documentation, published by Viator.
- Viator Connectivity Quality Program, which sets the service levels, the error ceilings and the five operator precondition.
- OCTO, the open connectivity standard the supplier endpoint and the reseller client are also certified against: octo.travel and docs.octo.travel.
Ownership