OTA APIs for Tour Operators: The Channel Manager Guide

If you are trying to plug your inventory into Viator or Expedia, the first thing to know is that you do not connect to either OTA directly. Tour operators never touch the OTA APIs themselves. You connect through your booking software's channel manager — the software you probably chose for its calendar view and payment processing, not for its OTA integration strategy. That software determines which OTAs your tours appear on, what fees stack on top of the OTA's commission, and whether you are locked into a system owned by the same company that owns the OTA.

This article maps the full connectivity landscape: which booking systems connect to which OTAs, what commission stacking costs you on top of the headline OTA rate, how the major OTA APIs actually work, and why the entire ecosystem was built for a product shape that is not yours if you run multi-day tours.

How do tour operators actually connect to OTAs?

Through your booking software's built-in channel manager. The booking system connects to each OTA via API, syncing availability, pricing, and bookings in real time. You do not write API code — the booking system handles the technical integration. But the choice of booking system determines which APIs are available to you.

What is a channel manager for tours and activities?

A channel manager is the technology layer that connects your booking system to multiple OTAs through a single integration. When a traveler books on Viator, the channel manager updates your availability across all connected OTAs automatically. When you block out a departure, every connected platform reflects the change.

Three roles in the connectivity stack:

Booking system — your core software. FareHarbor, Bokun, Rezdy, Peek Pro, Ventrata, Xola, TrekkSoft. Manages your calendar, processes payments, handles customer communication. This is the operational layer you interact with daily.

Channel manager — the distribution layer. Often built directly into the booking system. Connects your inventory to multiple OTAs simultaneously. Some booking systems have robust channel managers; others connect to only a few OTAs or require third-party middleware.

OTA API — the OTA's connection point. The Viator Supplier API, the GetYourGuide Integrator Portal, Booking.com's intermediary feed. Each OTA exposes an API that certified booking systems connect to. The operator never sees this layer directly.

What is OCTO — and why does an open standard matter?

The Open Connectivity for Tourism standard (OCTO) is an industry initiative founded in 2019 to standardize how booking systems and OTAs communicate. Over 130 implementations as of 2026, with a 2.0 draft released in February 2026. OCTO reduces integration time between a booking system and a new OTA by an estimated 86%.

Why this matters for operators: without a standard, every OTA-to-booking-system connection is a custom integration. Switching booking systems means rebuilding every OTA connection from scratch — a migration cost that functions as lock-in. OCTO is still emerging, not universal, but it represents a structural shift toward making booking system switches less painful.

Which booking systems connect to which OTAs?

This is the most operator-useful section of this article. The choice of booking system is not just an operational decision — it is a distribution decision.

What does the booking system landscape look like in 2026?

Data verified against each system's current documentation as of April 2026. "Yes" means a documented integration exists; actual availability may vary by region and plan tier. Partner designations (Premium, Advanced, Top) reflect the OTA's certification tier for each booking system.

Bokun and Rezdy offer the widest OTA connectivity. But the choice between them is not about breadth — it is about economics and independence.

What do the ownership relationships mean for operators?

Two vertical stacks dominate the connectivity landscape:

The Tripadvisor stack. Bokun (booking system) + Viator (OTA) + TripAdvisor (discovery). Bokun waives its per-booking fee on Viator reservations — the single biggest financial incentive in the connectivity landscape. An operator on Bokun pays 25% to Viator and $0 to Bokun on that booking. An operator on any other system pays 25% to Viator plus 1-5% to their booking system. The savings are real. So is the lock-in: the more volume you push through the Tripadvisor stack, the more expensive it becomes to leave. See the full breakdown in TripAdvisor's vertical lock-in.

The Booking Holdings stack. FareHarbor (booking system) + Booking.com (distribution surface). FareHarbor routes inventory to Booking.com via the FareHarbor Distribution Network at 20-25% commission — the only pipeline for independently operated tours onto Booking.com. See Booking.com's intermediary model for the full walkthrough.

Independent systems — Rezdy, Peek Pro, Ventrata, Xola, TrekkSoft — connect to the same OTAs but without the cross-subsidy. Operators using independent systems pay full platform fees on every OTA booking. The trade-off is independence: no parent company steering your distribution toward its own OTA.

How does commission stacking work?

On every OTA booking, you pay the OTA's commission (20-30%) plus your booking system's per-booking fee (1-6%). The total effective rate is higher than the OTA commission alone — and the difference varies by booking system.

What does the math look like on a multi-day trip?

A $4,500 multi-day trip booked through Viator at the standard 25% commission:

The Bokun-Viator 0% exception saves $131-225 per traveler compared to independent systems. On a 30-traveler departure, the Bokun advantage is $3,930-6,750. Over a 6-departure season, $23,580-40,500 — the cost of an entire booking system subscription, several times over.

Is the Bokun-Viator fee waiver really "free"?

The fee waiver is real. Bokun's pricing page confirms 0% booking fees on Viator reservations across all paid plans. On paper, this makes Bokun the cheapest option for any operator distributing through Viator.

But the savings create a switching cost. If you leave Bokun for an independent system, you start paying 1-5% on every Viator booking immediately. The more volume you push through Viator via Bokun, the more expensive it becomes to leave Bokun. That is how vertical integration works — the discount is the lock-in mechanism.

An operator who recognizes this can still choose Bokun rationally — the savings are substantial and the trade-off may be worth it. The point is to make the choice with eyes open, not to discover the switching cost two years and $40,000 in accumulated savings later.

How do the major OTA APIs actually work?

Brief overviews in operator language — enough to understand the architecture, not to build an integration.

How does the Viator Supplier API work?

The Viator Supplier API is REST-based, POST-only, and accepts JSON or XML. Operators do not connect directly — you connect through one of Viator's 100+ certified connectivity partners (the booking systems in the table above). The booking system must implement mandatory APIs for batch availability, real-time pricing, booking creation, and cancellation processing.

Viator's 11 featured connectivity partners — Bokun, FareHarbor, Peek Pro, Regiondo, Rezdy, TourCMS/Palisis, travelotopos, TrekkSoft, Ventrata, Xola, and bookingkit — have the deepest integration and the highest certification tier. Operators on non-featured systems may have limited functionality or longer integration timelines.

For the full analysis of why Viator's commission structure is hostile to multi-day operators, see the Viator supplier walkthrough.

How does the GetYourGuide API differ?

GetYourGuide runs a tiered partner program: Premium partners (Bokun, Rezdy, Ventrata) get the deepest integration and priority support. Advanced partners (bookingkit, FareHarbor, Regiondo, TrekkSoft, and others) get standard integration. The tier affects API capabilities — Premium partners receive proactive availability change notifications and annual performance incentives.

Rate limits are tighter than Viator: 1,000 requests per hour per partner. This matters for high-volume operators syncing large catalogs.

For the full analysis of GetYourGuide's country-based rates and the product-taxonomy mismatch for multi-day, see the GetYourGuide supplier walkthrough.

What about Booking.com and Expedia?

Booking.com has no direct API for tours. All inventory flows through intermediaries — Musement, Viator, Klook, or FareHarbor. Your booking system connects to the intermediary, not to Booking.com directly. The operator is two layers removed from the distribution surface. (Full details in Booking.com's four-intermediary pipeline.)

Expedia has a Local Expert API but is no longer onboarding new suppliers. Inventory is sourced from Viator and GetYourGuide. A Rapid Activities API is in early access for B2B partners. For most operators, reaching Expedia means listing on Viator or GetYourGuide and letting their distribution pipelines carry inventory to Expedia's platform.

Why are multi-day operators underserved by this ecosystem?

Every major booking system and every OTA API was designed for single-day activities: one time slot, one capacity count, one price point, one departure time, last-minute booking windows. Multi-day tour operators using these tools are forcing a 14-day itinerary through a pipeline designed for a 2-hour walking tour.

What was this ecosystem built for?

The short answer: a traveler in Lisbon this afternoon who wants to book a 2-hour food tour that starts at 3 PM. One time slot. One price. One capacity count. Booked 24-48 hours out. Delivered and reviewed by tomorrow. Every OTA product page, every booking system calendar, every channel manager sync protocol was designed for this shape of product.

Where does it break for multi-day tours?

Five specific pain points, not generic complaints:

Itinerary representation. OTA product pages are optimized for single-day activities. A 14-day trekking itinerary with per-day details, accommodation types, included meals, and altitude profiles does not render well in a product card designed for a "2-hour walking tour with tapas."

Booking window mismatch. OTA product pages are built to surface activities travelers can book in the next few days — last-minute, in-destination shoppers. Multi-day tours sell 3-12 months in advance. The platforms that promote day tours effectively bury multi-day departures because the booking window does not match the traveler behavior they are built for.

Cancellation policy conflicts. GetYourGuide's standard 24-hour free cancellation policy is designed for day tours where the operator's marginal cost of an empty slot is low. On a $4,500 multi-day booking where the operator has already committed deposits to lodges, transport providers, and local guides, a last-minute cancellation is a material financial loss.

Payment structure. Multi-day tours need deposits with balance due weeks before departure. OTA checkout flows process full payment at booking and pay the operator after the experience is delivered — sometimes weeks after. The deposit-balance-final payment cadence that multi-day operators depend on does not exist in any major OTA's checkout.

Group size management. Multi-day operators manage availability across multiple days with shared supplier commitments. A single cancellation on day 5 of a 14-day trip affects lodge bookings, vehicle capacity, and guide assignments across the remaining days. Standard OTA availability APIs track single-slot capacity — they have no concept of cross-day dependency.

What should multi-day operators look for in booking software?

The answer depends on where OTA connectivity sits in your distribution strategy.

When does OTA connectivity matter for multi-day operators?

It matters if you sell short activities alongside multi-day trips — a day-tour cross-sell strategy that uses OTAs for the short products while driving multi-day bookings through your own website. It matters less if your entire operation is multi-day trips over $2,000, where the OTAs are not designed for your product shape and the channel management overhead may not justify the distribution value.

For multi-day operators considering TourRadar specifically — the one OTA built for multi-day — see the TourRadar evaluation.

What features should multi-day operators prioritize?

Six capabilities that matter more than OTA connection count:

Deposits and installment payments. Native support for "30% deposit at booking, balance due 60 days before departure." Not a workaround. Not a Zapier workflow. A first-class payment feature.

Multi-currency supplier payouts. Your lodges are invoicing in local currency. Your travelers are paying in their home currency. The booking system needs to handle both without requiring you to manage the conversion.

Day-by-day itinerary management. Not a single-slot calendar. A multi-day view that represents each day of a 14-day departure with its own details, capacity, and supplier assignments.

Direct traveler communication. WhatsApp, email sequences, pre-departure briefings. Multi-day trips require weeks of communication between booking and departure — communication the OTA checkout cuts you off from.

Group size management across departures. A single departure involves interconnected bookings across multiple days, suppliers, and capacity constraints. The booking system needs to manage this as a single unit, not as 14 independent day-slots.

Direct booking as the primary channel. OTA connectivity is optional incremental distribution. The booking system's primary job is to make direct booking — your highest-margin channel — as smooth as possible.

Further reading: zoom out to the full OTA supplier guide, compare platform fees against the 2026 OTA commission rates reference, work through the OTA vs direct booking math, follow the cross-platform 8-step listing checklist, and read how Expedia's supply-feed model reshapes channel strategy.

Samba is built for this. Deposits, installments, multi-currency payouts, WhatsApp communication, itinerary management — native, not bolted on. OTA connectivity is incremental. Direct booking is the default. Book a demo.