Application Programming Interface (API)

The most common analogy for a Application Programming Interface (API) is a waiter in a restaurant.

• Menu: Travel agency website where the customer searches for a flight.
• Kitchen: Airline’s internal reservation system (PSS), which holds the actual inventory and prices.
• Waiter (API): The customer gives their order (e.g., JFK to LHR on Nov 12) to the waiter. The waiter takes this request to the kitchen, gets the result (Flight available for $450), and delivers it back to the customer’s screen.

Without APIs, an OTA like Expedia would have to manually download and store the pricing of every single airline in the world every minute, which is computationally impossible. APIs allow them to simply ask the airline’s server at the exact moment the traveler hits the search button.

The travel industry is currently undergoing a massive technological transition regarding how these APIs (Application Programming Interface) are built.

• Legacy Era: Historically, systems talked via EDIFACT (highly compressed, cryptic codes) or older SOAP APIs using XML (heavy, rigid, and verbose).
• Modern Age: Today, the industry standard has shifted to RESTful APIs that use JSON (JavaScript Object Notation). JSON is incredibly lightweight, mobile-friendly, and much faster to process. This modern architecture allows airlines to send rich media (like photos of business-class seats) through the API, a core requirement of NDC (New Distribution Capability).

In travel distribution, APIs generally operate in two distinct ways to keep inventory accurate:

• Pull API (Shopping): The OTA pulls data. When a user searches, the OTA pings the hotel’s API to ask, “Do you have rooms, and what is the price?”
• Push API (Updating): The hotel pushes data. When a hotel drops its price in its revenue management system, the system automatically pushes that new price out through an API to all connected OTAs simultaneously to ensure rate parity.