The API advantage: connect, automate and thrive

AeroTime is excited to welcome Ann Cederhall as our columnist. An instructor with IATA on Airline Distribution Strategy and with Aeroclass on Airline Retailing, Ann is a frequent speaker and panelist at industry events. She has authored numerous highly regarded articles and white papers in the travel industry press. As one of the owners of the consulting firm LeapShift, Ann brings an extensive track record of delivering business value in project and product management roles worldwide.   

The views and opinions expressed in this column are solely those of the author and do not necessarily reflect the official policy or position of AeroTime. 

Many are surprised when I tell them that most airlines in the world are not API (application programming interface) focused. It tends to be treated as “yet another function” within their PSS (passenger service system), rather than as a core business priority. When managed by the PSS, commercial conditions are common.  

Even more surprising is how many airlines don’t even have an API; they have not made any development with web services to enable communicating directly. This is a far cry from the narratives of the International Air Transport Association (IATA) initiatives NDC and ONE Order. 

I keep saying that it is critical that you control your distribution and that is why an API matters.   

But even for those airlines with an API it is astonishing how they lack the capability to exchange data and send it back to sellers. A seller needs the information on the ticket (or record of purchase) and updates to changes. As always it is the low-cost airlines (LCCs) who are the leaders, their direct sales matter most and therefore API capability is a must along with communication with other vendors and sellers. 

It is surprising that so many airlines say, “we let our PSS vendor manage our API like our NDC API”. I also find it remarkable that airlines talk about specific online travel agents and even name them in contracts. In the ever-changing world, where acquisitions are happening left right and center, it is a good move to avoid narrow definitions. 

It has been interesting to observe Ryanair going all in with all the partners it wants to work with. By implementing an API, the carrier fully controls who sells its content. But of course, there is a drawback – implementing an API is time consuming.   

The time to implement complex travel APIs does not just come from technical complexity, but also business process complexity. Let’s break this down. Obtaining commercial agreements can take weeks and months of emails, calls and in-person sessions to accomplish. And what about the actual engineering work? I checked with the folks at Trapi, who ran user research by interviewing 100+ travel API integration engineers, and the average timeline to integrate a typical travel API is 59 working days – which is 11.8 weeks, or roughly three months. 

And now you think you’re all good to go, right? Nope… the next step is potentially one of the most painful: certification. This can be weeks and months of more emails, calls and meetings for the API provider to review and ensure that the integration done by its customer is up to standard, and incorporates all the mandatory requirements set out by the API provider. 

Once you are live with an API, the journey has just begun, deepening integrations with more/new features or upgrading to newer versions of an API can be very time consuming and take a substantial ongoing percentage of your engineering teams’ bandwidth. 

The most important question for an airline to ask themselves is, are they an airline operations company or a travel tech company or both? Very few are both.  

For an IT shop you need architects, API engineers, product managers, technical customer success managers (CSMs) to build and truly scale an API first business. If you do not have the resources, you need to find vendors to work with, but it is critical to understand that you need to be involved and help the vendor. When you compare vendors, you need to understand their integration experience.  

If you are a seller like a TMC (Travel Management Company) or Online Agent, you need to prioritize what matters most. Does it make more sense to use an aggregator who offers multiple connections, such as, GDS (Global Distribution Systems), LCCs, NDC content? You need to compare the solutions commercially to direct connects that offer much better margins but involve a higher complexity.  

There are 2,000 + APIs in travel tech alone making it one of the most highly API dense industry verticals. There are APIs for flight search, booking, GDS connections, airline direct connections, wholesale flights, direct hotels, GDS hotels, wholesale hotels, cars, rail, ground transportation. Tools that you need to integrate, such as expense management and audit, tours, experiences, payment. And I have not covered them all. Then we also have APIs for automation. 

The GDS, in all fairness, has been an excellent tool to aggregate data and process that data but it was built on PNR-centric technology dating back the 1960s, 70s and 80s using teletype, EDIFACT and type B messaging. It is not cost effective and struggles with anything not defined in the PNR environment. The same goes for most of the PSS – messaging standards leave room for improvement. We are currently seeing the GDS competing with their own business and offering NDC solutions, but we see little or no modernization of messaging or PSS API communication.  

There is no doubt in my mind that we will eventually move towards a modern world of selling travel which will mean aggregation of content or rather facilitating how to find and point to content. In future we may not even need to aggregate, just use pointers. There is so much content I wish I could easily access, for example, comparing private charters to regular flights. To create a massive omni marketplace is a great ambition but maybe not realistic. I don’t know. But I do know that communicating using APIs is the way forward. 

Modernization may not only be about API first strategies, but also about the changes to search. Will the larger processing capabilities of data allow us to search better? I always question why we need to process all fares there are between a city pair and then filter the results. Shouldn’t filters be applied from the start? 

But let’s go back to the airline requirement, how do you get started?  

These are the questions you should ask yourself: 

Do you want to distribute directly and to whom? Agents? Corporate customers? Leisure travelers? To decide on this, you need a business case.  
Do you have an API or not? And do you have any constraints on using it? If you do you need to plan how you make changes. An example is if you are in a full content agreement, then you most probably don’t need direct distribution.  
You also need to plan internally (people, process, technology) to make an API first distribution happen. So many airlines I come across say “we just need an NDC schema API”. Sorry, that is a simple piece. The rest is far more challenging.  

The biggest hurdle with NDC is the inability of the airlines to scale their API products. They do not have the resources, the processes or the tech. I have heard medium-sized travel selling businesses telling me that there is a 12–18-month waitlist to get on their API and that doesn’t even include the actual integration timeline. What this means is that the airline de facto limits agency access.   

It is also very important to have a good think about why you want a direct distribution strategy. My immediate answer to that would be to lower costs and to sell content in the same way as on your website. You need to compare vendors and have a clear picture of the cost structure. You could argue that by competing with themselves the GDS should lower costs and improve content and processes but this you would need to evaluate.  

Regardless of direct distribution you need to identify which APIs you need to implement. I always recommend that you use an orchestrator (OMS – order management system) as it makes it so much easier.   The post The API advantage: connect, automate and thrive appeared first on AeroTime.

Go to Source