Ai Editorial: Airlines need to be wary of proprietary APIs

First published on 15th July, 2016

Ai Editorial: Proprietary APIs tend to create “one-off” implementations that make repeatability more complex and therefore more expensive, writes Ai’s Ritesh Gupta

 

Airlines are increasingly opting to control their own merchandising, e-commerce and API technologies.

The focus is on using platforms that enable airline control, faster speed to market, and flexibility – and drifting away from solutions that are hard coded or community-model based, or tied to a particular PSS or channel.

As carriers gear up for personalisation, yield-managed offers, it is clear that they need to sharpen their respective APIs (application programming interfaces). Amidst all the talk around a single, standardized set of XML messages that can feed all channels, how are airlines and GDS companies going about the same? It seems we haven’t yet settled for standardization i. e. relying on XML APIs or set of codes so that structured data can simplify processing and new application development.  

Proprietary APIs – airlines need to be wary of them

NDC-XML is a messaging standard, and not a model or a system. Whether an airline is using XML or any other messaging standard, they will get feedback on their offer when someone purchases it.  But proprietary APIs are not always scalable for widespread adoption.

I recently interacted with the Chinese platform Alitrip's team and it emerged that they have signed direct connect agreements with domestic carriers in China. But these aren’t NDC XML APIs.

“Proprietary APIs tend to create “one-off” implementations that make repeatability more complex and therefore more expensive,” said Jim Davidson, CEO, Farelogix.   

He added, “Proprietary APIs are where we started, and generally it makes scaling more complex and expensive, hence the necessity for standardization. Even standardized APIs are subject to implementation interpretation which we are already seeing with the NDC APIs.”

So how complex it is to change APIs and switch over to NDC XML one?

“It is a process for anyone who has developed to a certain API, as they must reprogram to the new API. Certainly some change, and updating will always be required as new functions and services are added to the API. Standardization allows for developers to get familiar and comfortable with certain APIs, even when they change a bit from time to time. This all adds to greater adoption and utilization which is a good thing,” explained Davidson.

APIs and travel distribution

API’s are all over the place, and companies like Google have thousands. The concept of API utilization in travel distribution is about content delivery and the concept often referred to as the single point of truth. In terms of content delivery, an API generally has the capacity to deliver more interactive content than traditional (i.e., older) types of connectivity. Car, hotel, and even airline APIs have been around for years. “However, they tended to be a bit fragmented in their structure – meaning no two were really alike – so scaling was both challenging and expensive. For the concept of a single point of truth, an API can function as that one place anyone can go to for consistent and reliable (and accurate) content,” said Davidson.

NDC – still a long way to go

So when we compare the way carriers like American Airlines, British Airways, Qatar Airways etc. with say ones in China, it seems there is disparity in adoption of NDC-XML coding. Proactive airlines have shown that it is possible to deliver richer, more personalized offers across multiple channels, and also possible for aggregators to more cost-effectively scale their integration efforts. As Davidson shared with us earlier this year, this is a major accomplishment and bi-lateral win for the industry.  We are seeing that play out in a number of forms – whether it is OTA’s such as Priceline consuming airline direct connects; GDS such as Sabre consuming American Airlines API etc. NDC-XML provides a strong first level of standardization where XML is used, and avoids many inefficiencies that different versions of XML can create. Based on this foundation, the industry will naturally and in practice further standardize how NDC-XML is applied in order to facilitate the widest adoption. This will involve a process of trial and error.

It is pointed out that GDSs have integrated airline content using proprietary airline API interfaces for several years. But GDS specialists are working their way, and even point out that IATA NDC standards are still new and emerging, and the airlines and airline IT providers are still assessing the role that NDC will play in the distribution of fares and content. “While some carriers are further down the path with their assessments and piloting solutions utilizing NDC standards for offer creation and order management, the majority of the almost 400 commercial airlines in the world are not. According to a recent IATA NDC survey, 86 carriers are planning to adopt the NDC standard in some capacity, while 93 are either undecided or not planning to adopt the NDC standard,” shared a source.

For their part, Sabre is closely engaged with IATA and ATPCO on the NDC initiative at both an executive level as well as a working group level.

“(Sabre) will be part of the group of industry constituents driving the evolution in this area,” Kathy Morgan, Director of Transportation Product Solutions, Sabre Travel Network told me in an interview.

In an interview with Ai earlier this year, Gianni Pisanello, Strategic Marketing Director, Airline Distribution, Amadeus did acknowledge the limitation of proprietary APIs and mentioned that NDC-XML will help increase scalability through a level of standardization. The industry will need to further standardize the data elements and the booking flows to benefit from full economies of scale. In order to deliver the economies of scale that everyone seeks and needs, the industry will need to continue to work closely together to find a balance between that flexibility and effective standardization as NDC-XML gets deployed.

Focus on centralized and standardized API

 “When it comes to a distribution approach to an airline’s selling channels, the delivery methodology would be quite clear, i.e., a centralized and standardized API that would be consumed by all channels – web site, kiosk, GDSs, mobile, etc. The technology behind the API is generally related to the functions one wants to deliver through the API. In the airline world its things like flight search, flight price, PNR create, ticketing, etc. It’s nothing really magical, but rather just a highly efficient way to communicate with the outside world,” Davidson said.

Looking at the bigger picture, Farelogix recommends that airlines not only need to work out standardized set of XML messages that can feed all channels, but also need to plan web and mobile front-end that can dynamically add or alter any fare, bundle or ancillary, and facilitate all offer types and corresponding functionality for shopping, booking, fulfilment etc.

 

Ai is set to host Complimentary MasterClass with Farelogix - NDC in Action: Best Practices in Airline Merchandising & Digital Commerce in Kuala Lumpur (on 22nd August).

Follow Ai on Twitter: @Ai_Connects_Us

Editorials

  • Ai Editorial: Botnet attacks on loyalty programs, how to negate them? +

    First Published on 21st July, 2017 Ai Editorial: Airlines need to guard themselves against data server breaches, malware or phishing programs in order to protect a loyal traveller’s login credentials Read More
  • Ai Editorial: Taking NDC forward – stabilize the schema for all +

    First Published on 19th July, 2017 Ai Editorial: NDC data standard is not only an airline topic. It also affects the travel industry across the board. Considering that there was Read More
  • Ai Video: Using APIs to monetize trip experience beyond flights +

    First Published on 17th July, 2017 Travel e-commerce players, including airlines, hotels, intermediaries etc. are finding ways to connect and access inventory and sales systems via application programming interfaces (APIs). Read More
  • 1
  • 2
  • 3
  • 4
  • 5