What is OCTO? The open standard for tour and activity connectivity

The connectivity problem every operator meets

Most tour and activity businesses sell through more than one channel. There is your own website, of course, but there may also be online travel agencies, regional resellers, hotel concierges, cruise lines, attraction passes and destination marketing sites. Each of those partners needs to know what you sell, when you have space, what it costs, and how to place and cancel a booking.

For years, every one of those links was built separately. A reseller wrote code for one booking system's API, then wrote different code for the next one, and so on. Booking system providers did the same in the other direction. The result was slow onboarding, expensive maintenance and many operators simply not being connected to channels that could have sold their products. When connections were missing, operators fell back on manual work: emailing availability, retyping bookings and hoping two channels did not sell the same last seat.

OCTO was created to reduce that duplicated work by giving the industry one shared way to describe the same basic conversation.

What OCTO is

OCTO stands for Open Connectivity for Tours, Activities and Attractions. Its own documentation describes it as an open standard API specification for the in-destination experiences sector of travel. In plain terms, it is a published, agreed description of how one system should ask another for products, availability and bookings, and what the answers should look like.

The specification is open: OCTO states that it is open source and available to anyone who wants to use it, so a booking system, reseller or channel manager can implement it without asking permission. It is developed by an industry organisation through a board, a specification committee and working groups, and companies can join as members to support the work and have a say in where the standard goes next. Membership is not required to use the specification.

It is important to be clear about what OCTO is not. It is not a marketplace, a booking system or a company that sells your tours. It is a common language. Two systems that both speak it can connect with far less custom work, but someone still has to build, test and switch on each connection.

How OCTO works, in plain terms

The core of the specification covers the steps any reseller needs to sell a product. Each step is a request from the reseller and a response from the supplier's booking system:

• Supplier: basic details about the business that runs the experiences.
• Products, options and units: what you sell (a product such as a canyon tour), its variations (options such as a morning or private departure) and who or what is being booked (units such as adult, child or a boat).
• Availability: which dates and start times have space, either as a calendar across a date range or as individual start times for a chosen day.
• Booking reservation: the reseller places a booking that is held for a short time, with a status of ON_HOLD, while the traveller completes payment on the reseller's side.
• Booking confirmation: the reseller confirms the held booking, which then becomes CONFIRMED. A hold that is not confirmed in time expires and the space is released.
• Cancellation: the reseller can cancel a booking, and the booking record says whether it can be cancelled and whether the refund is full, partial or none, in line with the option's cancellation cutoff.

Capabilities: optional extras on top of the core

Not every connection needs everything, so OCTO splits additional features into optional capabilities that a system can support and a reseller can ask for. The core stays small and stable, while capabilities add detail where it is needed.

According to the OCTO documentation, published capabilities include pricing, content (richer product descriptions and media), pickups and drop-offs, and a notifications capability is being developed to let systems tell each other about changes. Other capabilities, such as promotions, have been circulated in draft for feedback. Because capabilities are optional, two systems that both 'support OCTO' may support different sets of them, which is one of the most important things to check before you connect.

What OCTO means for an operator

You will rarely work with the OCTO specification directly. It matters because it changes what your booking system and your partners can do together:

• Faster connections: if your booking system and a reseller both implement OCTO, the connection can often be set up through configuration and testing rather than a new development project.
• One source of availability: resellers read live availability from your system and place bookings into it, so a seat sold on one channel is no longer free on the others.
• Fewer manual bookings: reservations arrive in your calendar with traveller details, rather than as emails to retype.
• Less lock-in: because the language is shared, changing booking system does not have to mean rebuilding every reseller connection from scratch, provided your new system supports the same capabilities.
• Holds that protect you: the reserve-then-confirm flow means seats are held only briefly while a traveller pays elsewhere, and are released automatically if the booking is never confirmed.

A worked example: one departure, three channels

Imagine a sea kayaking tour with 12 seats on Saturday at 9:00. You sell on your own website and through two resellers connected over OCTO.

On Monday, eight seats are left. A traveller on the first reseller selects two adults; the reseller checks availability, reserves the two seats with a hold of, say, 30 minutes, takes payment and then confirms. Your calendar now shows six seats left, and both your website and the second reseller see six the next time they check.

If the traveller on the first reseller abandons payment instead, the hold expires and the two seats return to the pool automatically. Without that hold-and-confirm flow, a reseller would either have to book immediately and cancel later, or risk selling seats that had already gone.

Now picture the same week without a connection: each reseller has a fixed allocation of seats, you update numbers by email, and on a busy weekend two channels sell the last place. A shared standard does not remove every problem, but it does make live, shared availability the normal way of working.

Questions to ask before you connect a channel

OCTO makes connections simpler, but every channel still has its own commercial terms and its own interpretation of the details. Before switching one on, ask these questions:

• Which version of OCTO and which capabilities does the channel support, and does your booking system support the same ones?
• How are prices handled: does the channel receive your retail price, a net rate, or neither, and who sets the price the traveller sees?
• How is your cancellation policy passed through, and what happens when a traveller cancels on the channel's side?
• Which traveller details are collected (lead name, every traveller's name, phone, email, pickup point) and do they match what you need on the day?
• How long are booking holds, and what happens to a hold when a traveller does not finish paying?
• How do vouchers or tickets work, and does your team need to scan or simply check a name list?
• How is commission recorded and paid, and how will you reconcile it with your own bookings?

Mistakes to avoid

Most problems with new connections come from rushing the setup rather than from the standard itself:

• Connecting every product at once. Start with one or two products, place and cancel test bookings, then add the rest.
• Assuming 'OCTO compatible' means identical. Check the capabilities on both sides, especially pricing and content.
• Letting product set-up drift. If options and units are named inconsistently in your system, resellers will show them inconsistently too.
• Leaving fixed allocations in place alongside a live connection, which brings back the overbooking the connection was meant to prevent.
• Not checking the cancellation rules each channel shows travellers against your own policy.
• Forgetting reconciliation. Match channel bookings and commission against your records at least monthly.

OCTO and distribution in Tourtify

Tourtify's Channel manager plugin lets Tourtify act as an OCTO supplier for resellers: they read your supplier details, products and availability calendar, reserve, confirm and cancel bookings, and can subscribe to OCTO notifications, all from the same calendar as your website so seats are not sold twice. Alongside it, the Agents plugin gives travel agents, hotel concierges and affiliates their own referral link and commission rate, with statements of what you owe each one, and the Public API plugin lets your own systems read tours and live availability and create bookings using API keys with scopes, an OpenAPI description and webhooks.