This blog post is written by Stu Waldron from TTI's Associate Organisation: Open Travel Alliance.
There’s something soon to be announced by the OpenAPI Initiative (OpenAPIs.org , A Linux Foundation project) that could have a large impact on travel API providers, and more importantly, API consumers (channel and apps).
Travel may be unusual in that there may be more labour hours spent on consuming APIs than creating and supporting APIs. Think about it, every travel provider now publishes their products and services via APIs. Most are created by the travel providers themselves even when they may contract out the actual development. That is, they publish customised APIs.
There is a lot of increasingly advanced API tooling available meant to increase the productivity of the API developer. But what about the API consumer? This group includes channels like online travel agencies but also the GDSs, consolidators, TSCs, switches, and of course the suppliers themselves when they want to direct connect to another suppliers. Lets not forget startups trying to make that killer app to get into the travel retail market.
I can speak from experience having been a VP of architecture at a major GDS, the nightmare of being an API consumer in travel. Multiple thousands of availability APIs, each needing custom code as they do nearly identical work but data and format varies.
What’s really varied is the workflow of a common booking flow (shop, availability, order, payment, fulfilment, etc.). Travel APIs at best are described in a text document (PDF, etc.) which frequently is out of date and/or at a high level, hence lacking the detail necessary. The docs often focus on the “happy path” and leave out many of the possible use cases. This leads to many hours of trial and error testing by API consumers to sort it all out.
OpenAPI already produces a specification which allows the API developer to describe the structure and attributes of the API. This is predominantly used by tool vendors to automate the process to publish an API for use.
What is being added is a spec of similar design that allows for the description of the relationship of one API to the next. This spec describes the sequence of APIs and the passed data elements in a way that allows tool providers to start automating the workflow itself. Early use may be to allow an API consumer to easily see how a sequence of APIs work together in what is called a mock test.
Down the road the automation will extend to the runtime itself by generating code that will handle the various use cases. Given the proliferation of similar but different APIs in travel, this approach can have a dramatic impact by lowering the (labour) cost to bring new travel content on board via APIs. Reducing the current very long lag time to onboard new content by a retailer. At OpenAPI, I run a travel special interest group working on prototyping common travel API workflows using the new spec. As we get those reference implementations done, they will be published on the OpenTravel website.
I presented this and other OpenAPI activity on April 15th at the Linux Foundation Open Source Summit in Seattle. You can access the pdf at https://static.sched.com/hosted_files/ossna2024/47/OpenAPI%20MiniSummit%20April%202024.pdf.