How to connect your tours to GetYourGuide and Viator without paying for a reservation system

There are three routes onto GetYourGuide and Viator, and only one of them involves buying a reservation system. You can manage each channel by hand in its own supplier portal, you can pay for a reservation system that is already connected, or you can connect through a marketplace that already runs one and holds your calendar. Which of the three is open to you depends on how many departures you run, whether the same seats are for sale in more than one place, and whether a marketplace that has already done the integration work is already carrying your tours.

Operators usually meet this question in the same order. A channel says yes to your product. The channel then asks how you will keep availability up to date, and the answer that comes back is a subscription to a reservation system you did not plan to buy. That is one answer. It is not the only one, and it is not always the right one.

What follows is the whole decision, including the parts that do not involve us. The figures quoted are requirements published by GetYourGuide and Viator, and they apply to whatever you connect with.

What a channel is actually asking for

Strip away the vocabulary and a channel wants one thing: something that answers, quickly and correctly, when it asks whether a seat is free and then asks to take it.

The GetYourGuide Supplier API defines six mandatory endpoints: availability query, reservation, reservation cancellation, booking, booking cancellation, and an availability update notification that GetYourGuide hosts. Authentication is HTTP Basic in both directions, and OAuth and bearer tokens are not accepted. Every response is HTTP 200, with any error carried inside the JSON payload rather than in the status code.

The speed expected is specific. Response time targets, in seconds, as desired, 95th percentile and longest acceptable: reserve 1, 3 and 10; book 2, 4 and 10; cancel a reservation 1, 2 and 4; cancel a booking 1, 4 and 6; availability for one day 1, 3 and 6; availability for thirty days or more 5, 10 and 15. Monthly error ceilings sit underneath those: availability under 0.01 percent, reserve under 1 percent, book under 0.5 percent, and booking cancellation under 0.5 percent. The availability commitment is 99.8 percent per calendar month, and a call that is not answered within 15 seconds counts as unavailable.

There are human requirements too. A named technical contact has to answer within 24 hours or the next business day. Mapping information has to be supplied to any supplier who asks for it, within two business days. Changes that affect connectivity carry at least 30 days of notice. Reservations hold seats for a window of sixty minutes desired, and fifteen minutes at the absolute minimum, while a traveller pays.

None of that is negotiable by an operator, and none of it is difficult to understand. It simply means that something has to be awake and answering on your behalf. There are three ways to arrange that.

Option one: manage each channel by hand in its own portal

How it works

You list the product in each channel's own supplier portal, set the dates and seat counts there, and close dates out by hand when they fill or when the weather takes them. Bookings arrive by email and portal notification, and you copy them into whatever you actually use to run the day, which for a great many good operators is a diary or a spreadsheet.

What it costs

No software subscription, and no connectivity fee. The channel's own commission applies as it always does. The real price is attention, and it scales with the number of departures multiplied by the number of channels. Two channels and one daily departure is a few minutes a day. Two channels, six products and multiple start times is a job.

Where it breaks

Every channel holds its own copy of your availability, and each copy is only as current as the last time you touched it. A seat sold on one channel stays sellable on the other until a human removes it. Nobody oversells on purpose. They oversell because a booking arrived while they were on the water for eight hours with no signal.

You can cap that risk without any software. Give each channel a fixed allocation rather than the whole boat, so the worst case is bounded. The cost of that safety is stranded seats: the allocation you gave to a channel that did not sell is a seat the other channel could have sold.

Who it suits

Operators with few departures, generous capacity, and long booking lead times. It is a legitimate starting point, and it is how most operators begin. It stops being tenable at the point where the last seat matters and same day bookings are common.

Option two: pay for a reservation system that is already connected

How it works

You buy a reservation system, move your products, prices, seasons and capacity into it, and it becomes the calendar of record. Its software answers the channel's calls for you, and it has already been through each channel's certification. Your commercial relationship with the channel usually stays your own.

What it costs

A subscription, and in many cases a fee per booking as well. Beyond the invoice, the cost is migration and discipline. Connectivity does not improve a calendar, it broadcasts it: if the availability in the system is not right, being connected simply distributes the mistake faster and to more people.

What you get for it

One calendar behind every sales route, including your own website and your walk up sales, plus the surrounding machinery: point of sale, manifests, vouchers and reporting. You are also not dependent on any one marketplace, which matters if you sell in several places and want none of them to be structurally necessary.

What to ask a vendor

Ask what the connection costs per booking, and whether that rate changes depending on which channel the booking came from. GetYourGuide requires fee parity: the fee charged for sales through its Supplier API must not exceed the fee charged for any other similar sales channel. Ask which channels are certified today rather than planned, and ask for the product mapping in writing once you are live.

We do not publish a comparison of these products. We compete with them, the terms change, and a table written by an interested party is not research. Ask two operators who already use the one you are considering.

Option three: connect through a marketplace that already runs a reservation system

How it works

If your tours are already listed with a marketplace that holds a real calendar, that marketplace's system can answer the channel's calls for the products it holds. You continue to manage departures, seats and blackout dates in the portal you already use. There is no second calendar, and there is no subscription for the connectivity itself.

What it costs

The marketplace's own commercial terms, plus whatever it charges for connectivity, which may be nothing. The less obvious cost is dependency. Your channel connection lives inside a commercial relationship, and if that relationship ends, the connection ends with it.

What to ask before you rely on it

• Who holds the Supplier ID and the contractual relationship with the channel: you, or the marketplace?
• Is the seat check performed inside the same transaction that writes the booking, or is availability copied somewhere and reconciled later?
• What happens to the channel listing, and to the reviews attached to it, if you stop working with that marketplace?
• Which channels are certified today, and which are described as planned?

Who it suits

Operators already working with such a marketplace, who do not need a point of sale or a back office and simply want the channels to be able to see the truth. This option only exists where a marketplace you already work with has done the integration work, so for most operators it is available or it is not, and there is nothing to decide.

What Viator requires before any of this applies to it

Viator requires that the reservation system already has registered operators using it, meeting a published Connectivity Quality Program minimum of five active engaged operators, before development may commence. That requirement lands on the system rather than on you, and it is worth planning around separately because it catches new systems and the operators who are counting on them.

A system that has just been built cannot begin with Viator, however well written it is. If a vendor tells you Viator connectivity is coming, the useful question is how many active operators are using that vendor today.

The Viator integration itself is larger than the GetYourGuide one. The mandatory APIs are 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. The cached calendar has its own refresh cadence: every 2 hours for the next 0 to 2 days, every 1.5 days for 3 to 30 days out, every 3 days at 90 days, every 4.5 days at 180 days, and every 7 days beyond that. Service levels are 99.8 percent uptime for the critical synchronous APIs and 99.5 percent for the asynchronous ones, with monthly error ceilings of under 1.5 percent for availability check, under 1.5 percent for reserve and under 0.75 percent for booking. Support targets are expressed as mean time to acknowledge and to recover in business days: 2 and 5 for a critical S1, 3 and 14 for a major S2, and 5 and 90 for a moderate S3.

The pricing rule that decides what you can list on Viator

Viator supports per-person pricing only. Tiered pricing and per-unit pricing are not supported. If your product carries one price for the whole vessel or vehicle whatever the number of travellers, that price has to be re-expressed per person before the product can be sold through Viator connectivity.

For some operators that is a small piece of arithmetic. For a private charter sold as a unit, it changes what the product is, and it is worth deciding whether you want to sell it that way before anyone starts building. That constraint belongs to Viator, so check the equivalent rule on any other channel rather than assuming it is the same.

Questions worth asking before you commit to any of the three

1. How many departures do you run, times how many channels? That number is the manual workload, every week, for the rest of the season.
2. Which system answers the availability call, and does it hold the seats or a copy of them?
3. What happens when two channels ask for the last seat in the same second? A good answer describes a mechanism. A weak answer describes how often it happens.
4. What does the connection cost per booking, and does the rate differ by channel? GetYourGuide requires parity with other similar sales channels.
5. Who holds the Supplier ID, and who is the channel's counterparty: you or the software?
6. How do you leave, and what leaves with you?
7. For Viator specifically, does the system already meet the five active engaged operators requirement, or is it waiting to?

Where RezRoute fits

This section is the part of the guide where we are an interested party, so it is kept in one place and you can skip it without losing anything.

RezRoute is the third option, for two marketplaces: The Greek Local in Greece and Cyprus Bucket List in Cyprus. RezRoute is owned by the company behind Cyprus Bucket List. If your tours are listed with either marketplace, the channel's calls are routed to that marketplace's own calendar, the seat check happens inside that marketplace's own database transaction, and you keep working in the portal you already use. If your tours are not listed with either, this option is not available to you, and options one and two are the real choice.

On price: connectivity is free for operators working with The Greek Localor Cyprus Bucket List, with no monthly fee, no setup fee and no charge per booking. The pricing page carries the full terms, including what would have to happen before that changed.

On status, plainly: RezRoute is built to the GetYourGuide Supplier API specification, and GetYourGuide certified this connection on 20 October 2026 after its Supplier API live test. The first supplier was connected through self-mapping on 21 October 2026. Viator has not been started, for the reason described above, which is that Viator requires five active engaged operators on the system before development may commence. No measured uptime or error figures are published, and the numbers in this guide are the channels' requirements rather than our results. Current status is kept on the channels page, with the endpoint surface and the certification stage for GetYourGuide and the blocking requirement for Viator set out in full.

If you take a different route

Most operators reading this will choose option one for a season and then move, or will buy a reservation system because they want the back office as much as the connectivity. Both are sound decisions. The requirements quoted here are set by GetYourGuide and Viator, not by us, and they hold whatever you connect with, including a spreadsheet and a very disciplined person. The point of the guide is that you should be able to tell which of the three you are choosing, and why.