The online travel industry is made up of a complex web of distribution channels and networks. Travel product suppliers such as hotel companies and airlines need to interconnect with aggregators and distributors such as wholesalers, metasearch and GDSs to reach as large an audience as possible for their rooms and seats. Meanwhile suppliers are also becoming distributors not only of their own products but also ancillaries such as cars, parking, ground transportation, other seats and rooms, or even local events. In fact going forward the list of possibilities will grow.
The whole industry is underpinned by a complex layer of networks and APIs – the plumbing of the B2B travel industry – e.g. communication links and API connectors between merchandising platforms, central reservation systems, global distribution systems, industry transaction hubs and gateways, etc.
The aim is to connect supply with demand in the most “convenient” way. The speed by which Internet users expect things to happen and the tendency to do a lot more shopping before booking – with the inevitable consequence of burdening systems and networks adds to complexity.
In buying and selling travel products there are countless applications, servers and networks talking to each other every day 24/7 to make travel requests, receive responses and offers, do deals (confirm deals or sometimes cancel them) and ensure payments end up in the right place. Basically in the world of Internet travel bookings there is an awful lot of messages being pumped around the system, much of it in XML. Thank goodness for Application Programming Interfaces (APIs) that provide the underlying standards to enable the exchange of information (and XML messages) between systems.
What is an API?
These days, most web services have an API. The word is thrown around a lot and a lot of non-technical people don’t really understand what an API is. At a simple level, an API is a set of programming instructions and standards for accessing a web-based software application or tool. They are the sets of requirements that govern how one application can talk to another. A travel company develops and makes available an API so that other travel companies can send information requests to its systems, and of course receive the replies, usually containing dynamic information such as prices and availability.
It is easy to think of APIs in this context as doors that let XML messages in and out of a Web service. Like doors, they only swing in a certain way at a given time. And they are typically open only to those applications that have keys to the lock (i.e the rules or passwords).
An API is a software-to-software interface, not a user interface. With APIs, applications talk to each other without any user knowledge or intervention. So for example, when you buy an airline ticket online and enter your credit card information, the airline ticket web site (whether the brand.com or via an OTA uses an API to send your credit card information to a remote application that verifies whether your information is correct. Once payment is confirmed, the remote application sends a response back to the ticket provider web site saying it’s OK to issue the tickets.
The online purchaser only sees one interface — the OTA or airline web site — but behind the scenes, many applications are working seamlessly together using APIs.
For travel suppliers (i.e. hotels and airlines), there is a lot of innovation taking place by young companies wanting to fill a gap in planning and booking travel experiences. Delivering specialised or integrated travel services from a single sales platform is a key trend in the industry made possible by established suppliers opening up their APIs, to enable access to their rich content and functions. You just have to look at the success of online travel agencies and metasearch engines.
Indeed the web of APIs connecting suppliers with new and emerging innovative sales platforms will continue to drive the next phase of growth in the travel industry as they help travel companies sell more than they could by selling on their own.
(Article originally published by triometric)