The Definitive Guide to Travel APIs
Cutting-edge applications in the travel industry heavily rely on third-party APIs and web services. Take TripActions: the corporate travel management software connects to the United Airlines API, the Southwest Airlines API, and the Lufthansa Group API to import their content like flight schedules and fares. Likewise, it connects to human resources APIs (Namely, BambooHR), finance APIs (Expensify, Spendesk), travel services APIs (VisaHQ, Stasher), and more. APIs underlie TripActions’s entire product, and they aren’t alone in relying heavily on APIs.
Whether you are building a business-to-business (B2B) or a business-to-consumer (B2C) travel application, APIs should be at the core. Why? The entry barriers are too high to build the features and offerings of a first-rate product in-house. Consuming third-party APIs help developers deliver a better product sooner and at significantly lower costs.
The drawback is that you lose control over the performance of your software. What happens to TripActions when its airline providers have downtime? Customers can’t book a trip. Who do they blame? TripActions, because this is the software they have in front of them. Developers need to protect themselves from third-party API incidents. How? Let’s dig into that.
Table of contents:
- Who should integrate with travel APIs
- Why you should use a travel API
- Types of API providers
- Travel APIs by Category
- The most common issues you will have with travel APIs
Who should integrate with travel APIs
First, a quick overview of who should think about using third-party APIs and web services.
Online Travel Agencies (OTA)
An online travel agency (OTA) sells travel products (flights, accommodations, car rental, cruises, tours, etc.) to consumers through its website. It can resell tickets, services, and products it sourced from APIs.
Travel Management Companies (TMC)
A travel management company (TMC) also sells travel products sourced from APIs, but to professionals and businesses. So its solution must also support features such as expenses, human resources and accounting management, which means API integrations with the relevant software.
B2B and B2C Travel Applications Providers
Travel application developers will rely on third-party APIs to enrich their product catalog, offer integrations with other software, and thus provide a better experience to their users. Some also make a business of integrating with numerous providers’ APIs and reselling it to developers through an API of their own.
Property Management Systems (PMS)
A property management system (PMS) is a set of software solutions used by Property Owners and Hoteliers to manage their day-to-day operations. They will integrate with hotel and accommodation APIs to ensure their property listings are up-to-date in the provider’s application.
Channel Managers help small businesses sell their products online across different channels, and in particular OTAs. As a result, they often look for integrations with OTAs APIs.
Why you should integrate with travel APIs
Enrich your offerings
Distribution in the travel industry used to be proprietary. If you wanted to book a flight, you had to go to the airline’s website. It changed gradually as third-party distributors emerged like Expedia for flights and Booking for accommodations. Travelers got used to a unified search experience on a single website or application.
Now they expect services to offer a complete set of results because they don’t want to browse dozens of websites. Travel applications should consolidate inventories from multiple suppliers to ensure they provide their users with the best catalog on the market.
Integrating with multiple suppliers can take time. Fortunately, there are API providers who already took that hassle for you. For example, Skyscanner lets you search for flights and get flight prices from its huge database with its Travel APIs. What used to take months to develop can now be released within hours.
Obviously, speeding up time-to-market means lower development costs. And as end data is managed by API providers, maintenance costs are lower. Your team can focus on what makes your offerings unique (UX, marketing, building custom packages, etc) rather than managing content. If you work for a Travel Agency, think of the time that could be saved by agents who spend hours searching manually for offers on their numerous providers’ websites.
Types of API providers
Global Distribution Systems APIs
The old guard of the online travel world. Global Distribution Systems APIs (GDSs) are the main source of data for many OTAs and provide 5 types of reservations: flights, hotel rooms, car rentals, trains, and cruises. The market is dominated by three players: Amadeus, Sabre, and Travelport.
They allow OTAs, Channel Managers, Transport Management Companies (TMCs), and Enterprises to avoid integrating with hundreds of suppliers, and instead use a unified API. For instance, Expedia connects to the Amadeus API.
In return, API consumers have to pay a heavy Distribution Cost Charge, such as 16 € per flight ticket, and are dependent on the negotiations between the GDS and airlines for their catalog (and it does not always go well). Generally speaking, GDSs are not a good choice if you are a small or medium business.
Online Travel Agencies APIs
OTAs are the cornerstone of the online distribution strategy. Hotels, airlines, tour activities, and more are often covered by OTAs. Many travelers use OTAs like Expedia or Booking to book trips, as they outrageously dominate the online travel selling market.
They often integrate with GDS APIs, and in turn provide their own API to smaller companies that don’t have the resources or desire to interact with the GDS directly. For instance, Guesty integrates with Airbnb API and Booking API.
Metasearch engines APIs
Metasearch engines build a catalog aggregating data from various OTA websites across the internet. These include: TripAdvisor, Kayak (owned by Booking), Skyscanner, Trivago (owned by Expedia), and Google Hotel Ads.
The TripAdvisor Content API allows developers to incorporate all of its content—name, rating, reviews, price category from restaurants, accommodations and attractions—into their application.
Travel APIs by Category
Flight APIs allow developers to import flight schedules and fares. A few options here:
- GDSs APIs like Sabre, Amadeus, and Travelport.
- OTAs and aggregators APIs like Expedia, Booking, Skyscanner, Kiwi, Momondo, and Kayak
- Airlines APIs like Lufthansa, British Airways, American Airlines, and Iberia. The International Air Transport Association (IATA) introduced the New Distribution Capability (NDC) in 2012: a XML standard which allows airlines to bring richer content—like ancillaries—to travel companies via a set of APIs. As a result, many airlines recently started providing a public API to third-party developers.
- Flight booking APIs like ATPCO and Duffel (which already integrates with 20+ airlines APIs).
- Flight data (schedules, routes, etc.) APIs like SITA, Innovata, OAG, and FlightStats.
If you need to sell hotel rooms, you should review:
- GDSs APIs like Sabre, Amadeus, and Travelport.
- OTAs APIs like Expedia and Booking.
- Bed banks APIs like Hotelbeds, WebBeds, HotelsPro, Travco and Bonotel. Airbnb also used to expose an API. Unfortunately they don’t accept new access requests anymore.
- Connectivity and Channel Manager APIs like CloudBeds, Dhisco, DerbySoft and SiteConnect.
Car Rental APIs
With flights and accommodations, this is usually the third of the gang. As with the above-mentioned APIs, you can go with:
- GDSs APIs like Sabre, Amadeus, and Travelport.
- OTAs and aggregators APIs like Rentalcars (by Booking), Priceline, Skyscanner,Travelfusion and CarTrawler.
- Tech service providers APIs like Travelpro, Trawex and eTravos.
- Car rental suppliers APIs like Avis.
Similar to flight APIs, rail APIs allow developers to import train schedules and fares to sell them in their application. You can have a look at:
- GDSs APIs like Sabre, Amadeus, and Travelport.
- OTAs and aggregators APIs like Travelfusion, Ctrip and Qunar.
- Tech service providers APIs like Trainline, Omio, TravelFusion, Travelpro, Trawex and eTravos.
- Railways APIs like Amtrak Railways (USA), and the UK National Rail Enquiries.
Other Transports APIs
If you’d like to complete your transportation offer with taxis, buses, trams and metros, you can use:
- Public APIs provided by cities. There are hundreds of them, like Los Angeles Metro’s Realtime API or Paris Subway API which give the location of metros in real time.
- APIs from applications which integrated data cities into their systems: Google Maps Directions, Citymapper, HERE and Moovit.
- Ridesharing and Taxi APIs like Uber and Lyft. For instance, TripAdvisor uses Uber API to request its service.
Location Data and Traffic APIs
Most travel applications have location-based requirements due to the escalation of mobile usage. You can use geocoding and location data APIs to add location awareness to your application like Google Maps, Mapbox, PredictHQ, Airship and HERE.
Tours & Attractions APIs
Besides OTAs like Booking and Expedia, other third-party services aggregate tour and activity offers from local suppliers and share it through APIs, along with ticket purchasing capabilities: Bokun, Rezdy, Ticketmaster, Viator, Tiqets, and Ceetiz among others.
Property Management Systems APIs
If you are building a solution targeting hoteliers, and willing to integrate with their existing software solutions, first have a look at the most used Property Management Systems: Oracle Hospitality, Cloudbeds, Protel, Guestline, Mews, and SIHOT.
Impala is already connected to most of them and provides its own API to help developers connect their application to hotel data in just a few hours.
Business Travel APIs
For developers building B2B travel applications. The main player on the market is SAP Concur. For example, Uber uses Concur API to give travel administrators visibility into their employees’ expenses on Uber rides.
There are plenty of other APIs used for non-travel specific purposes. Here are some of the more popular solutions:
- CRM APIs to manage your customers (Salesforce, Hubspot, Zoho, Pipedrive).
- Communication APIs to email and text customers (Sendgrid, Mailgun, Nylas, Twilio, Nexmo).
- Marketing APIs to attract and retain customers (Intercom, Mailchimp).
- Payments APIs to add payment capabilities to your website (Stripe, Paypal).
- Expenses, HR and Accounting APIs for B2B travel application (Xero Quickbooks, Softledger).
The most common issues you will have with travel APIs
The more critical APIs are to your application, the closer you should look at them. You may already know this if you consume third-party APIs: issues can arise from an infinite number of reasons, cripple your software, hurt your customers, and damage your reputation permanently. As Skycanner experienced in October 2019, API incidents happen.
Many travel API providers do not have a status page and those that do only update it manually for large-scale incidents. So you can’t rely on them to accurately detect the below-mentioned issues.
API is down
API requests are timing out or returning responses with a 5xx error code, like Service Unavailable (503). The error is not on your side: your API provider is experiencing a major outage. As a result some of your services may be fully non-functional.
This time the error is on your side. You are making invalid API requests which return an HTTP response with a 4xx error code. The content of you request may be invalid because:
- Invalid parameters are sent - Bad Request (400)
- The application access token has expired or was revoked - Unauthorized (401)
- You do not have the appropriate user rights to access the request - Forbidden (403)
- The resource specified in the request was not found - Not Found (404)
- Your application has been rate limited - Too many request (429)
The best thing to do is to read the Handling Errors or the Status Codes page of your API provider which often explain how to deal with such issues. As a reminder, here are the most common status codes.
If you encounter low-level errors without a status code (ECONNRESET, ENOTFOUND) and the server is not returning any response, then you are experiencing connection errors. This often comes from connectivity issues between client and server.
Error rate is elevated
An increasing number of 4xx and 5xx errors will negatively impact part of your users. It may be focused on a particular endpoint, on a geographical region or on a particular segment of users.
API is slow
High error rates often come with high latency, especially when errors are timeouts. A slow application is no better than one which does not work.
Say you are using Mapbox to geolocate your users and suggest surrounding activities or transportation options for them. High latency and elevated error rates means your application has become completely useless to some of them.
API consumption spiked.
An abnormal increase of API requests is dangerous. First because it may overwhelm your API provider, increase latency, and return timeouts. Or because you could be rate-limited and thus unable to use the API temporarily. It could also cost you tons of money: if you use Google Maps API, you know that you pay on a per usage basis. What happens if the number of calls you make skyrockets by error? The bill’s going to be a hefty one.
Rate-limiting is a client-side error which often returns a response with a 429 error code. It comes from a limitation set by the API provider on the number of API request you can perform in a given time-window. For instance, TripAdvisor set a daily calls limit to its Content API to 10,000.
If you are curious, we wrote an article about how to fix the “Too Many Requests” error.
API has been deprecated
Many travel applications used to rely on Google QPX Express API (formerly Google Flight API) for airfare data. Unfortunately, the API closed in October 2017. Unforeseen deprecation is a more common problem than you might think.
Concerned providers always include deprecation warnings in response headers. They include information about when the API or the endpoint will be deprecated so that you can plan for the future like using the latest version of the API or switching to another provider.
APIs offer hackers a new attack surface. The Indian search engine JustDial, which sells flight tickets, leaked its entire database in 2019. The personal data of more than 100 millions people were leaked because its API endpoints were publicly accessible to anyone, without authorization nor encryption. Unthinkable, isn’t it?
Do you have an exhaustive list of your API providers? Do you know which data you are sending them? How exposed you are to sensitive data breach? You should not assume you are protected if you can’t answer these questions.
How should you handle these issues?
The first step is knowing that a problem exists. Are you alerted in real-time every time your APIs are down? You should if you want to fix issues before they impact your users so you can effectively communicate the problems and, if possible, mitigate them.
The second step is efficiently troubleshooting. Do you have all the information you need to debug fast? Logging your HTTP requests and responses will provide it to you.
Lastly, implement a failure recovery strategy. If you are eager to learn how to do it, we wrote a dedicated article.
These are core features we build into Bearer. Give it a try if you are tired of finding out about API issues too late and taking too much time fixing them.