The news
The global travel industry has had an interoperability problem for decades. Every traveller who has ever stood at an airport gate, flight cancelled, trying to reach a hotel on one phone and a car rental on another, both of whom cannot see each other's systems and neither of whom can see the airline's — has felt it directly. It is not a minor inconvenience. It is a structural failure in the way the industry was built.
Someone has now built the missing layer.
The Activity Travel Protocol is an open standard that gives every party in a travel booking — hotels, activity suppliers, transport operators, AI agents, travellers, and the platforms that connect them — a shared language for the complete journey. From the first inquiry to safe return home. Across multiple suppliers, multiple jurisdictions, and however many AI agents are involved in assembling and managing the trip.
It is published. It is live. It is Apache 2.0 — open governance, no single owner, free to implement.
This post explains what it is, why it matters, and what the travel industry looks like when it actually works together.
Why this was hard to build
The travel industry is not short of standards. Airlines have NDC — a well-established protocol for distributing fare and ancillary content through modern APIs. Hotels have OpenTravel — a schema library for accommodation data. Payment security has FAPI 2.0. Identity has OpenID Federation. These are real, working standards that the industry built and maintains.
The problem is that each of them solves one slice of the journey. NDC handles the airline seat. OpenTravel handles the hotel room. Neither was designed for the booking that spans both — and neither begins to address the ski school, the local guide, the transfer service, or the equipment rental company that together make the trip what it actually is.
The gap is not just about data formats. It is about the booking lifecycle. When a traveller's flight is cancelled and they are sitting at a gate in a foreign airport, the question is not "what is the hotel's check-in time schema?" The question is: who is responsible for this traveller right now? Who can initiate a rebooking? Who needs to be notified? In what order? What are the rules?
No existing standard answers those questions. And the arrival of AI agents in the booking chain makes the absence of an answer urgent rather than merely inconvenient. An AI agent that can book a complex multi-supplier itinerary autonomously — without a defined authority scope, without a verified credential, without a protocol-level record of what it was permitted to do — is a liability problem waiting to happen. Regulators in the EU, Japan, Singapore, and the United States are already asking who is accountable when an AI travel agent makes a consequential mistake.
The industry needed a standard that addresses the full journey, not a slice of it. One that was built for the AI era from the ground up, not retrofitted to it. And one that is genuinely open — not owned by a platform with its own commercial interests in how the standard develops.
What the Activity Travel Protocol does
The Activity Travel Protocol is structured in four layers. Each layer solves one part of the interoperability problem. Together they form what the specification calls a Travel Operating System — a runtime platform that manages the full lifecycle of a booking as a first-class entity.
| Layer 1 | Identity and Trust | Every party in a booking — hotel, ski school, taxi operator, traveller, AI agent — holds a verified credential. The Security Kernel checks it before any state transition is allowed. |
| Layer 2 | Discovery and Capability | Suppliers publish structured Capability Declarations. Any OTA, AI agent, or platform can read them through a single protocol interface. One integration, every supplier in the network. |
| Layer 3 | Workflow | The Booking Object state machine manages the full lifecycle — inquiry through to safe return. Disruption handling, duty of care transfer, and AI agent participation all governed by protocol rules. |
| Layer 4 | Schema and SDK | The developer layer. OpenAPI 3.1 schema, TypeScript and Python SDK, MCP server for AI agent integration. Build on the protocol without reading the specification. |
The central concept is the Booking Object. Every booking in the protocol is a shared, append-only record — its commercial state, its duty of care assignments, its event history, the credentials of every party involved, and the authority scope of every AI agent that has touched it. It is not a database entry. It is a runtime entity, with its own state machine, its own rules, and its own lifecycle.
When something goes wrong — when the flight is cancelled, when the hotel cannot accommodate the original check-in, when weather closes the mountain — the Booking Object is the shared truth that every party can read. The protocol defines what happens next: which events trigger which responses, who holds duty of care at each moment, how a Disruption Event Declaration propagates across every affected booking simultaneously. The traveller is not the integration layer. The protocol is.
What interoperability actually means in practice
| Without a shared standard | With the Activity Travel Protocol |
|---|---|
| Each OTA builds bilateral integrations with each supplier. N suppliers × M OTAs = N×M integrations, each maintained separately. | Every supplier publishes one Capability Declaration. Every OTA reads it through one interface. The network effect works for everyone. |
| When a flight is cancelled, each downstream supplier — hotel, activity, transfer — has to be contacted separately. The traveller is the integration layer. | A Disruption Event Declaration propagates across every affected Booking Object. Suppliers are notified simultaneously. The traveller is not the integration layer. |
| Duty of care is tracked through contracts and after-the-fact liability. No real-time record of who is responsible for a traveller at any given moment. | Duty of care is a first-class runtime state. It transfers formally between parties at each journey phase, with a timestamped record for every handoff. |
| AI agents make bookings with no defined authority scope, no verification, and no audit trail for regulators or harmed parties. | Every AI agent holds a declared, verified authority scope. The Security Kernel enforces it at every state transition. Human confirmation required at defined checkpoints. |
What the industry looks like when it works together
Interoperability is not a technical achievement. It is a commercial one. The travel industry is built on relationships — between OTAs and suppliers, between hotels and activity providers, between tour operators and the local businesses that make their itineraries worth buying. Those relationships have always existed. What has been missing is the infrastructure that makes them machine-readable, verifiable, and scalable.
The Activity Travel Protocol provides that infrastructure. A hotel in Nagano that wants to offer its guests a complete winter experience — accommodation, ski pass, equipment, guided backcountry day, transfer from the station — can now connect to every activity supplier in the region through a single protocol interface, with verified credentials, structured commercial terms, and a duty of care chain that covers the guest from arrival to departure. No custom bilateral integrations. No legal grey areas around packaging. No manual coordination when something changes.
A major OTA that wants to offer AI-powered itinerary assembly can do so without building bespoke integrations for hundreds of thousands of activity suppliers, and without running expensive AI inference on every step of the workflow. The protocol's state machine handles the orchestration. The AI handles what AI is actually good at: understanding what the traveller wants.
A regulator who wants to know who was responsible for a traveller's welfare at the moment of an incident has a timestamped, machine-readable duty of care record in the Booking Object. The accountability chain is not reconstructed after the fact from email threads. It was maintained in real time by the protocol.
And a traveller who has their flight cancelled at a foreign airport has, for the first time, a booking system that already knows what needs to happen — and is already doing it.
That is what the industry looks like when it works together. Not a utopia. Not a solved problem in the way that ending a war is a solved problem. A protocol. An open standard. A shared foundation that every party in a booking can build on, in their own interest, in ways that also happen to be good for everyone else.
The Activity Travel Protocol is that foundation. It is built. It is published. The rest is adoption.