What Is OCTO? The Open Connectivity Standard for Tours and Activities

For most of this industry's history, connecting a supplier to a reseller meant two engineers on a call agreeing what to call a child ticket. Then doing it again with the next partner. Then discovering that partner three calls it a youth and defines it as ages four to fifteen rather than three to twelve.

OCTO stands for Open Connectivity for Tours, Activities and Attractions. It is a specification maintained as an open standard, and its ambition is narrow and useful: agree the shapes once, so the interesting work can be about inventory rather than about field names.

The core model

OCTO's data model is small, which is its strength. Six things matter.

If you have read our piece on API distribution, this will look familiar, because most well-designed private APIs converge on the same three-level product model independently. OCTO's contribution is writing it down and fixing the field names.

Two availability types, and why that is enough

OCTO models availability with a single field on the product, availabilityType, and it takes one of two values.

START_TIME means the traveller is buying a specific departure. Each departure is its own availability object with its own capacity. A 09:00 walking tour and an 11:00 walking tour are two availabilities on one option.

OPENING_HOURS means the traveller is buying a date. The availability object covers the whole day and carries the opening hours as a range. A general admission museum ticket works this way, and so does a bike rental.

Two values looks reductive until you try to break it. A multi-day tour is START_TIME with a long duration. A city pass valid for thirty days is OPENING_HOURS with a validity window on the voucher. A timed-entry aquarium slot is START_TIME. The model holds up remarkably well, which is a sign that it was designed against real inventory rather than in the abstract.

The booking lifecycle

This is where OCTO is most opinionated, and rightly so. Bookings move through defined states and the transitions are explicit endpoints rather than a status field you patch.

1. POST /bookings reserves. The booking is ON_HOLD and carries an expiry. Capacity is held but not committed.
2. POST /bookings/{uuid}/confirm commits it. Status becomes CONFIRMED and tickets are issued.
3. POST /bookings/{uuid}/cancel releases it, applying the cancellation terms and returning a refund decision of FULL, PARTIAL or NONE.
4. POST /bookings/{uuid}/extend pushes the expiry out if a checkout is taking longer than expected.
5. PATCH /bookings/{uuid} amends details that do not affect capacity, such as a corrected surname.

The two-step hold is the single most valuable thing the spec insists on. It is what lets a reseller guarantee a price and a seat to a traveller while a card payment is in flight, and it is what makes a failed payment a non-event rather than a reconciliation task.

Capabilities: how the standard stays small

Every standard faces the same pressure. Someone needs pickup points. Someone else needs waivers. Someone else needs seat maps. Add them all to the core and the core becomes unimplementable.

OCTO handles this with capabilities. The core response contains only the core fields. A client opts into extensions by sending a header:

GET /octo/products HTTP/1.1
Authorization: Bearer {key}.{secret}
Octo-Capabilities: octo/pricing, octo/content

The server merges the requested capabilities' fields into the response and echoes back which ones it actually applied, so a client can detect that it asked for something unsupported.

The capabilities worth knowing about:

Note what this implies. A bare OCTO response has no prices in it. That surprises people the first time, and it is deliberate: pricing is genuinely optional for some integrations, such as a supplier feeding their own retail site.

Money, handled properly

One detail worth calling out because it prevents a whole class of bug. OCTO expresses money as an integer in the currency's minor units, alongside an explicit currencyPrecision.

{
  "currency": "EUR",
  "currencyPrecision": 2,
  "original": 4500,
  "retail": 4500,
  "net": 3600
}

That is forty five euros, not four thousand five hundred. The precision field is what makes it work across currencies that do not have two decimal places. Japanese yen has zero, Kuwaiti dinar has three. A float would have quietly mangled all three of those cases, and floats in price calculations are how rounding errors become accounting discrepancies.

What adopting it actually involves

If you are a supplier deciding whether to implement OCTO, the honest assessment is this.

The hard part is not the HTTP. It is discovering that your internal model does not cleanly separate product from option, or that your cancellation terms are stored as a paragraph of English, or that your capacity is tracked per day when you actually sell per departure. OCTO will surface every one of those, which is uncomfortable and also the point.

The payoff is that the second reseller integration costs a fraction of the first. And the third costs almost nothing. That is the entire economic argument for a standard, and in this sector it is a strong one, because distribution breadth is how tour operators grow .

If you are a reseller, the calculation is simpler still. Integrate OCTO once and every OCTO-compatible supplier becomes a configuration change rather than a project.

Where OCTO does not help

It is a connectivity standard, not a commercial one. It says nothing about what commission you charge, how you settle, or who owns the customer relationship. Those remain negotiations.

It also does not solve content. Two suppliers can both be perfectly OCTO compliant and still describe the same kind of tour completely differently. Mapping their products into consistent categories on a marketplace is still work, and the octo/content capability standardises the fields rather than the writing inside them.

Those are reasonable limits for a standard to have. It does the part that benefits from agreement and leaves alone the part that benefits from competition.