Travel API Distribution Explained: How One Inventory Reaches Many Resellers
Connecting your tours to other people's websites sounds like a technical problem. It is mostly a modelling problem. Get the model right and the integrations are easy, get it wrong and every new partner costs you a month.
The short answer
Travel API distribution is the practice of exposing one supplier's live inventory through an API so that many resellers can search, price and book it without ever touching the supplier's own system. It works when the supplier models inventory as product, option and unit, exposes availability with stable identifiers, and separates reserving a booking from confirming it.
Every operator eventually reaches the same moment. A reseller emails asking for a rate sheet and an availability feed, and you realise you have neither, because until now your availability has lived in a shared calendar and your rates in a PDF from last season.
What that reseller is really asking for is an API. Not because they enjoy integrations, but because the alternative is a human retyping your availability into their system, and that human will get it wrong on a Friday in August when it matters most.
Push or pull, and why pull usually wins
There are two ways to get your inventory into someone else's system.
Push means you send them your catalogue and your calendar, usually on a schedule, often as files. It is simple to start and it degrades badly. The feed is stale the moment it is written, so either you push constantly or your partner sells dates you have closed.
Pull means they ask you, live, at the moment a traveller is looking. Your system answers with what is true right now. It is more work to build and it is the only model that scales past a handful of partners.
In practice serious distribution is pull for availability and price, push for change notifications. The reseller asks you when they need an answer, and you tell them when something changes underneath a booking they already hold. That combination is what webhooks are for, and we will come back to them .
The model everything hangs on
This is the part that determines whether integrations take a week or a quarter. Nearly every well-designed distribution API in this sector uses the same three-level model, and it is worth internalising even if you never write a line of the code.
| Level | What it is | Example |
|---|---|---|
| Product | The thing a traveller recognises and searches for. Carries the marketing content, the photos, the location. | Sultanahmet sunrise walking tour |
| Option | A separately bookable variant of that product. Has its own capacity, times, cancellation terms and price. | 07:00 departure, or 09:30 departure, or the private version |
| Unit | A priced seat class within an option. Carries age rules, quantity limits, and how much capacity it consumes. | Adult, child, senior, or a vehicle that seats six |
The reason this matters so much is that resellers build their interfaces around it. Their search results page shows products. Their date picker shows option availability. Their passenger selector shows units. If your API collapses two of those levels into one, every reseller has to write custom code to un-collapse it, and they will quote you accordingly.
The most common modelling mistake
Treating every departure time as a separate product. It inflates your catalogue, it fragments your reviews, and it makes your listings compete with each other in the reseller's own search results. Departure times are availability on one option, not different products.
A unit is more subtle than it looks. The key field is how much capacity one unit consumes. An adult consumes one seat. A family pass might consume four. A private charter consumes the entire boat. Getting that right is what stops you selling twelve family passes into a minibus with sixteen seats.
The four calls that make up a sale
Strip away the optional capabilities and a distribution API is four operations.
1. Catalogue
Give me your products, their options, and their units. This is the slow-changing part. Resellers cache it, usually for hours, sometimes for a day. Do not put prices that change daily in here, put them in availability.
2. Availability
For this product and option, across this date range, what can I sell and for how much. Two variants are normal: a calendar call that returns one object per day for painting a month view, and a detailed call that returns one object per bookable departure.
The critical output of the detailed call is a stable identifier for each bookable slot. The reseller quotes that identifier back when they book. Without it you are matching on date and time strings and you will eventually book someone onto the wrong departure across a daylight saving boundary.
3. Reserve, then confirm
This is the one people get wrong. A booking should happen in two steps, not one.
The first call holds the seats and returns a booking in a pending state with an expiry. The reseller now has a guaranteed price and a guaranteed seat while they take the traveller's payment. The second call confirms it, at which point the seats are committed and the voucher is issued.
Do it in one step and every failed card payment becomes a phantom booking you have to reconcile manually. Do it in two and the hold simply expires, releases the seats, and nobody has to do anything .
4. Cancel
Given a booking, apply the cancellation terms that were in force when it was made, return the refund amount, and release the capacity. The terms must be the ones from booking time, not the ones you happen to have configured today.
Webhooks are not optional at scale
Pull answers the question at the moment it is asked. It cannot tell a reseller that the boat they sold seats on this morning has been cancelled for weather.
For that you need to push notifications. The events that actually matter are fewer than people expect:
- A booking's status changed, particularly to cancelled or rejected by you.
- A product or option became unavailable for dates that already have bookings against them.
- Content on a product changed materially, so caches should be refreshed.
- A voucher or ticket was reissued.
Sign them. An unsigned webhook is an open endpoint that anyone can use to tell your partner that a booking was cancelled. A shared secret and an HMAC signature over the body is the minimum, and it takes an afternoon.
What makes integrations expensive
Having watched a reasonable number of these go slowly, the causes repeat.
- Prices that only exist at booking time. If a reseller cannot get a price from the availability call, they cannot build a search results page, and search results are where travel is sold.
- Cancellation terms expressed as prose. "Free cancellation up to 24 hours" in a description field cannot be enforced by software. Express it as tiers with hours and percentages.
- No sandbox. If the only way to test a booking is to make a real one, integration takes four times longer and everyone becomes cautious.
- Unstable identifiers. If your availability identifiers change between the search call and the booking call, every booking becomes a race condition.
- Silent partial failures. Returning a 200 with an empty array when something went wrong teaches partners to ignore your responses.
The cheapest fix for all of them is to implement an existing standard rather than inventing a private one. That is the entire argument for OCTO, and it is why most new connectivity in this sector now starts there.
A reasonable sequence
If you are building distribution from nothing, this order front-loads the things partners test first.
- Model product, option and unit properly in your own database. Everything downstream inherits this.
- Expose a catalogue endpoint and get one partner reading it.
- Expose availability with stable identifiers and live prices.
- Implement reserve and confirm as two steps, with expiry on the hold.
- Implement cancel with terms captured at booking time.
- Add webhooks for status changes.
- Publish a sandbox with test credentials and at least one bookable product.
- Only then add capabilities like pickups, questions and promotions.
Steps one to five are the product. Steps six and seven are what turn a working API into one that partners actually finish integrating.
Frequently asked
What is the difference between a travel API and a channel manager?+
An API is the interface your inventory is exposed through. A channel manager is a product that connects to many such interfaces on your behalf and keeps them in sync. If you have one or two channels, an API connection is usually enough. Past that, a channel manager starts earning its fee.
Should availability and pricing be separate API calls?+
No. Resellers need the price at the moment they check availability, because that is what populates their search results. Splitting them doubles the request count and makes every results page slower, which directly reduces conversion.
How long should a booking hold last before it expires?+
Long enough for a card payment plus a retry, which in practice means fifteen to thirty minutes. Much shorter and legitimate checkouts fail. Much longer and a burst of abandoned carts can lock up a popular departure.
Do I need to support both push and pull distribution?+
Pull for availability and pricing, push for change notifications. Pure push of a full catalogue and calendar is only viable for small, slow-changing inventory, and it stops working the moment you have more than a handful of partners.