API Aggregator

To understand why we have API aggregators, you need to examine the enormous fragmentation of travel distribution.

If a new travel startup wants to sell flights from 50 different airlines, they have a daunting technical hurdle.

• Airline A uses a modernist JSON API.
• Airline B is working on a heavy, legacy XML SOAP connection.
  Airline C uses the new IATA NDC standard.
  Airline D is operating an old EDIFACT translator.

Building and maintaining 50 separate and custom integrations takes years of developer time. Furthermore, each time the airline changes its system, the connection to the start-up breaks, requiring constant and costly maintenance.

The API aggregator is in the middle. Companies like Travelfusion, Duffel, or Impala (in the hotel space) do the heavy lifting of building those 50 direct connections.

• Normalization: The data aggregator takes the messy and diverse data from all those suppliers and converts it into one clean and normalized format.
• Single integration: The developer at the startup only needs to code once to connect with the aggregator’s API.
• Instant inventory: Instantly the startup can search, price, and book inventory of all 50 airlines using a single set of commands.

While aggregators provide incredible time-to-market speed, they come with compromises:

• Middleman tax: Aggregators don’t do their business for free. They generally collect a per-transaction fee (i.e., $1 per booking) or a monthly SaaS license fee from the travel seller.
• Latency: Since the data must go through an extra layer (Supplier — Aggregator — OTA — Customer), the search time might be slightly longer than a direct connection.
• Feature dilution: Sometimes, unique features provided by a specific airline (such as a very specific meal choice) get “lost in translation” because the aggregator’s standardized API isn’t built to handle edge cases.