Think of APIs as a means to transport your product, a hotel room, airplane or rail seat, tour, cruise, rental call, etc. to a consumer. That’s the sole purpose of publishing an API that travel distribution channels or apps will consume. The traveler no more sees the API than a customer in a grocery store sees the truck that delivered the crate of oranges.
In retail , I can’t find any product provider that builds their own trucks. There are those like Amazon and Walmart that brand their own trucks, but they don’t make them. Yet in travel retail it’s very common for product providers to build their own APIs to transport their goods. There are some analogies to my example with Amazon and Walmart for product providers that are hosted on a service provider’s CRS/PMS, but the service provider is building their own trucks (APIs).
The distributor of the product in my grocery store example builds one type, one instance of a loading dock that can handle any truck. This is because trucks are fairly consistent in their shape, size and attributes. If a truck manufacturer made a truck taller, longer, wider than others they would not sell many trucks. They would be useless to perform their function to deliver goods to most business who are not going to build a loading dock for this unique truck. This is true of any mode of physical transport one can think of. If the truck, plane, rail, bus, ship, etc. cannot be accommodated easily by the receiver, it’s useless. But that’s exactly what we do in travel retail with APIs. Everyone creates unique APIs to transport their products, travel commodities like seats, rooms, cars, berths, etc. expecting the receiver to make accommodations for each supplier. Most would agree that the competitive value or differentiation of the travel product would be in the service it provides and at what price, not by what the digital truck that delivered it looked like. Yet over the decades I lost count of how many product teams I have worked with that did, and still think, proprietary APIs are a good thing.
A travel distributor, such as a GDS, aggregator, TMC, channels or others, has to deal with 1000s of bespoke APIs. In effect making and maintaining instances of bespoke loading docks. Some instances have minor differences, some major. Either way, any time there is a change required to the software, a major testing effort is required to validate all the bespoke instances.
All this comes at a high cost which needs to be passed on to someone. It may be in higher booking fees, transaction fees, or other types of service fees. It also adds to throttling of shop/availability messages where over a certain look to book rate it’s not worth it to a GDS or other distributors to deal with you. Same is true for taking on content from smaller providers like boutique hotels or tour operators. API support and processing costs are too high to turn a profit without charging unacceptably large booking fees.
It does not have to be this way. Today there is not a full standard for travel APIs that would guide not only what the message looks like but how the API behaves. Attributes that in our truck vs loading dock use case would have the same effect. That is, attributes that would allow API consumers to have one loading dock that can handle the delivery of any travel product.
Consistency in how travel retail APIs work would not only save distributors and channels loads of money, it would also greatly reduce cost for travel providers (providers of the APIs).
This is not a failing of the existing standards bodies. OpenTravel, OpenAPI and others are ready to work together to solve this. It’s the prevailing narrative in the travel industry that proprietary APIs are somehow a competitive advantage and a means to retain market share as it is hard to change providers. It’s narratives that everyone should follow the air standard (including non-air), while rail, hospitality, restaurants, tours and others also think they, not air, have the best standard. For others, they are building their own silos and don’t care what anyone else does.
It is also the lack of understanding that while you may in fact deploy some great APIs, it’s still going to mean high labor costs to someone else just because you are different.
In closing, you may make a really cool digital truck to deliver your product. But if everyone one who wants to work with you has to build a custom loading dock, your cool digital truck is a barrier to commerce, not an advantage.
