Guide
What a connectivity partner actually does in the GetYourGuide and Viator booking flow
A connectivity partner answers a sales channel when it asks whether a seat is free, and writes the channel's bookings into the calendar that holds your seats. Here is the sequence, step by step, with what you see while it happens.
Last updated 24 October 2026
What is a connectivity partner?
A connectivity partner is the software a sales channel talks to when it needs to know about your availability. Viator calls that software a reservation system, and GetYourGuide publishes its specification as a Supplier API, which is where the confusion starts: the software does not have to be a reservation system in the sense an operator means it. It has to be reachable, it has to answer quickly, and it has to be right.
What the operator does differently is close to nothing. You keep the calendar you already keep. The connection is a second door into the same availability, opened for the channel rather than for you.
Who is talking to whom?
There are three parties in the flow and only two of them are ever in a hurry. The traveller is on the channel website. The channel makes the calls. The connectivity layer answers them out of the marketplace database that owns the product. The traveller never reaches RezRoute directly, and neither do you.
What happens when a traveller searches?
The channel asks for availability, and the connectivity layer answers with the dates, times and remaining seats for that product. This happens constantly, for travellers who will never book, and it changes nothing in your calendar because it is a read.
GetYourGuide publishes response-time targets for this call, in seconds, as desired, 95th percentile and longest acceptable:
- Availability for a single day: 1, 3 and 6 seconds.
- Availability for thirty days or more: 5, 10 and 15 seconds.
GetYourGuide also sets a monthly error ceiling for availability of under 0.01 percent, which is the tightest number in the whole specification. That is deliberate: an availability call that fails is a search result the traveller never sees.
What you see: nothing at all. There is no notification for a search, and there should not be.
What happens when the traveller starts to pay?
The channel calls the reservation endpoint, and the seats are taken out of general availability for a fixed window while the traveller enters payment details. A reservation is a hold, not a booking. If the traveller abandons the checkout, the channel calls reservation cancellation, or the hold expires on its own.
GetYourGuide asks for a hold window of sixty minutes, and will accept no less than fifteen. Its response-time targets are 1, 3 and 10 seconds for a reservation, and 1, 2 and 4 seconds for cancelling one. The monthly error ceiling for reservations is under 1 percent.
The hold is the part of the flow that prevents overselling. While it stands, those seats are not offered to another channel, and not offered to a direct customer either, because there is one set of seats rather than one set per channel.
What happens when the booking is confirmed?
The channel calls the booking endpoint, and the hold becomes a confirmed booking with a reference the traveller and the channel can both quote. The seat check and the write happen inside the same database transaction in the marketplace that owns the product, which is why two channels cannot both be sold the last seat.
GetYourGuide targets 2, 4 and 10 seconds for a booking, with a monthly error ceiling of under 0.5 percent.
What you see: the booking appears where a direct booking appears, in the marketplace portal you already use, with the traveller details the channel passes across. RezRoute does not send you a separate message and does not ask you to log in anywhere new.
Money: the traveller pays the channel, not you and not RezRoute.
What happens when a booking is cancelled?
A cancellation made on the channel arrives as a booking cancellation call, and the seats return to availability at once. GetYourGuide targets 1, 4 and 6 seconds for this call, with a monthly error ceiling of under 0.5 percent.
The other direction is the harder one. If you cancel a departure that already carries channel bookings, the travellers are on the channel side and are handled under the channel policy that sold them.
What happens when you change your own availability?
The connectivity layer tells the channel, rather than waiting for the channel to ask again. When you close a date, add a departure or change a seat count, the channel needs to hear about it before the next traveller searches.
GetYourGuide handles this with the sixth endpoint, which is the only one it hosts itself: the connectivity system calls GetYourGuide to say that a product and date have changed. Viator works the other way round for the calendar, pulling a refresh on a published schedule, which is covered in the Viator guide.
What are the six GetYourGuide endpoints?
Five of them are hosted by the connectivity system and answered when GetYourGuide calls. The sixth is hosted by GetYourGuide and called by the connectivity system. In plain language:
- 01
Availability query
GetYourGuide calls it
Which dates and times are free for this product, and how many seats are left on each of them?
- 02
Reservation
GetYourGuide calls it
Hold these seats while this traveller finishes paying. Do not offer them to anybody else.
- 03
Reservation cancellation
GetYourGuide calls it
Release the held seats. The traveller did not complete the checkout.
- 04
Booking
GetYourGuide calls it
The traveller has paid. Turn the hold into a confirmed booking.
- 05
Booking cancellation
GetYourGuide calls it
This confirmed booking is cancelled. Put the seats back.
- 06
Availability update notification
GetYourGuide hosts it, the connectivity system calls it
Something changed on the operator side. Come and read this product and date again.
Two details that catch people out
Authentication is HTTP Basic in both directions. OAuth and bearer tokens are not accepted, which surprises anybody arriving from a newer API.
Every response is HTTP 200, including the failures. An error is carried inside the JSON payload rather than in the status code, so a monitoring setup that watches status codes alone will report a perfectly healthy integration while it refuses every booking.
Responsibility
What the connectivity layer answers for.
These are the obligations GetYourGuide places on a connectivity partner. They are requirements and targets, published by GetYourGuide, and they are what RezRoute is built against. None of them is a measurement of this service.
- Answering in time. The response-time targets above, per call type.
- Being reachable. An availability commitment of 99.8 percent per calendar month, where a call not answered within 15 seconds counts as unavailable.
- Staying inside the error ceilings. Availability under 0.01 percent, reservations under 1 percent, bookings under 0.5 percent, booking cancellations under 0.5 percent, measured monthly.
- Never confirming a seat that is not there. The seat check belongs in the same transaction as the write.
- Keeping the mapping straight. One stable Supplier ID per operator, and mapping information supplied to any supplier who asks for it within two business days.
- Being contactable. A named technical contact who answers within 24 hours or the next business day.
- Giving notice. At least 30 days notice of changes that affect connectivity.
- Fee parity. The fee charged for sales through the GetYourGuide Supplier API must not exceed the fee charged for any other similar sales channel.
Certification is not a form. GetYourGuide runs three testing phases: initial self-testing, advanced self-testing, and then live testing with its Connectivity team.
What it does not answer for
- Pricing and commission. What the channel charges, and what the marketplace charges, are set elsewhere.
- The traveller. Customer service on a channel booking belongs to the channel that sold it.
- Your product content. Photographs, descriptions and inclusions are managed where they always were.
- Being a reservation system. There is no RezRoute dashboard, no manifest, no point of sale and no reporting.
The other channel
How Viator is different.
Viator asks for a longer list of mandatory APIs: Tour List, Calendar v2.0, Availability Check v2.0, Event Notifications v2.0, Special Offer Notifications and Special Offers, Reserve v2.0, Booking, and Booking Cancellation. It supports per-person pricing only, so tiered and per-unit pricing cannot be carried over the connection. Its calendar is a scheduled refresh rather than a push, and its service levels are 99.8 percent for the critical synchronous APIs and 99.5 percent for the asynchronous ones.
Viator also requires that the reservation system already has registered operators using it, with a published Connectivity Quality Program minimum of five active engaged operators, before development may commence. That requirement lands on the reservation system, not on the operator, and it is why Viator is planned here rather than started. The full Viator guide covers what that means if Viator is the channel you need.
Status
Where this service stands today.
RezRoute is built to the GetYourGuide Supplier API specification. GetYourGuide certified this connection on 20 October 2026 after its Supplier API live test, and the first supplier was connected through self-mapping on 21 October 2026. Viator is planned and not started. No uptime figure, booking count or error rate is published. When one is, it will be measured rather than promised.
Channel status, kept current by hand, the GetYourGuide connection in detail, and the routing model in full.
Ownership