Building a Flight Aggregator for OTA: Hands-On Experience

An online travel agency (OTA) selling airline tickets typically faces the challenge of managing airline content from various sources, each with its unique “dialect” and workflow.  

In this article, we share our experience designing a unified flight API solution that brings together diverse suppliers. We’ll walk through the core design decisions, the engineering challenges we addressed, and what comes next as the platform evolves.

Why OTAs need multiple sources of flight content

Our client is an Israeli OTA wich operates a large network of branches and an online travel platform. The company provides a full range of travel services, including international and domestic flights, vacation packages, last-minute deals, organized tours, cruises, and more.

To access air fares, our client works with a mix of Global Distribution System (GDSs), global and regional flight aggregators, and consolidators. It may seem unclear why so many intermediaries are needed, since many OTAs limit themselves to one or two GDSs and are perfectly happy with that. Well, let’s work it out.

Multiple sources = broad content coverage

GDSs centralize a vast amount of flight inventory, providing travel agencies with unmatched access to full-service carriers (FSCs) and a mature booking and ticketing flow. Their value is self-evident. However, traditional GDS channels are no longer sufficient on their own.  

Many FSCs now push their most competitive deals, ancillaries, and branded offers exclusively through New Distribution Capability (NDC) channels. And while GDSs have been rapidly integrating NDC connections over the past few years, flight aggregators remain the primary source of NDC fares.

Besides NDC, flight aggregators link to suppliers outside the GDS ecosystem, including low-cost carriers (LCCs), charters, and small regional airlines. LCCs are crucial for the OTA’s budget-friendly deals, charter support package building and seasonal demand, and local suppliers cover domestic routes.

Finally, consolidators provide access to negotiated inventory, which is critical for competitive pricing.

Multiple sources = cost optimization and risk mitigation

Multiple providers enable cost optimization: certain channels may offer better prices for specific destinations, depending on contractual terms.

From an operational standpoint, maintaining a diverse set of booking channels also serves as risk mitigation. Content provider APIs vary in uptime, latency, and rate limits. For an OTA selling high volumes of tickets and packages, distributing traffic across multiple GDSs and aggregators increases resilience during outages and peak demand periods.

Ultimately, having a wide range of content sources helps OTAs mitigate external shocks, including regional geopolitical instability. For example, many major foreign airlines repeatedly suspended service to Israel and are only now cautiously returning. As a result, total weekly departures from Israel in 2024 dropped by nearly 40 percent year over year, leading to skyrocketing fares.

This means local OTAs may seek low-cost alternatives to offset high flag-carrier prices and access higher-margin inventory—such as consolidator fares and ancillaries—to maintain more stable profitability.

Multiple sources = tech and operational overhead? Not necessarily

All that said, multiple content sources come with a cost: increased technical complexity, higher operational overhead, and ongoing maintenance efforts. For our client — an organization that operates multiple points of sale, each targeting its own audience and relying on its own supplier base — this also resulted in content fragmentation, high integration costs, and recurring friction in revenue management.

That’s why our client decided to build a flight aggregator, a centralized inventory hub that consolidates all flight deals under one roof. At its core is a unified search-and-booking API that returns normalized, high-quality data across all channels.

The AltexSoft team has been involved in developing this product from the ground up. Below, we outline the key tasks the API solved and the lessons we learned during the development.

Multitenancy: catering to various agent needs

As mentioned earlier, our client OTA operates multiple offline and online branches, and also works with external business partners that have their own unique requirements. To support this diversity and simplify future integrations, we designed our API as a multitenant system, meaning it serves multiple agencies (tenants) from a shared backend while keeping each one’s configurations and access permissions logically isolated.

“You can pass the user ID in the request, and the hub will determine which configuration to load based on that ID,” explains Andrey Dudnik, Software Engineer who has been working on the project from the very beginning. “For example, there is the OTA website tenant, and there is also a partner bank. Both operate in the same environment but rely on different credentials and configuration parameters.”

When should you create a separate tenant versus sharing the same environment? It depends on how intensively the API will be consumed, the expected volume of search requests, and the nature of the partnership. Regardless of the setup, each user authenticates with their own agent credentials, which are securely stored in a key vault. The aggregation hub also enables each entity to define its own business rules—such as search preferences, result filtering, and markup pricing. Also, it’s up to the agent to decide which integrations to use.

Variety of integrations: each with its own development path

While all integrations are essentially about the same thing— airline content — no two followed the same development path. So, what connections were exactly added?

GDS content. Our client OTA collaborates with all three major GDSs — Amadeus, Sabre, and Travelport — with partnership depth and commercial terms varying between providers. At the time of writing, the API supported Amadeus, while Travelport was on hold and Sabre was being integrated.

Generally, each GDS assigns a dedicated account manager and support team to help resolve issues throughout an integration project. Whether you are in development or production, you can reach out to these experts whenever something doesn’t behave as expected. However, the responsiveness often depends on the size and importance of the client: the larger the business, the faster and more personalized the assistance. Bigger partners may also receive additional service privileges.

“Since our client is one of the key players in the Middle East region, Sabre and Amadeus responded to our questions very quickly,” Andrey says. “Amadeus even agreed to hold regular online calls where we could walk them through our issues, and their representatives helped us understand what was going wrong.”

For more detailed information, explore dedicated articles on hands-on experience with Sabre API integration and Amadeus API integration.  

NDC content. To source NDC content, the hub maintains connections with Amadeus NDC and Verteil, an NDC aggregator with access to more than 50 airlines. But what should businesses keep in mind when integrating NDC channels? Each airline takes its own approach to NDC, moving at its own pace and supporting a different API version and set of retailing capabilities. And while aggregators aim to streamline NDC booking flows and offer a consistent experience, the degree of uniformity still varies.

“When integrating a new NDC airline, you have to retest the entire flow and allocate time for fixes. In practice, 70–80 percent of the process stays the same, but the remaining 20–30 percent requires adjustments,” Andrey shares, describing his experience adding NDC content via Amadeus.

LCC content. The hub sources budget deals from Travelfusion, one of the world's leading travel content aggregators, widely known for its vast collection of LCC integrations.

Local content and leisure packaged deals.  For vacation packages, the hub integrates with ALP (the Amadeus Leisure Platform) and Sabre LDS (Local Distribution System) — two platforms that connect Israeli travel agencies with local, non-GDS suppliers, including charter operators and low-cost carriers.

The hub also links to Bravofly and AERTiCKET to support leisure travel. Bravofly, a long-standing metasearch and booking platform specializing in budget-friendly flights and packages, is used only for its metasearch capabilities, with bookings completed via redirection to its website. AERTiCKET, a well-established European consolidator working with both IATA and non-IATA agencies, provides broader access to air content. Both integrations are utilized by our client’s partner, a platform dedicated to sourcing affordable tours and deals.

In practice, each integration required a tailored engineering strategy and came with its own booking flows and API messaging standards — aspects that the aggregator API ultimately aimed to unify.

Unified booking flow: hiding diversity and complexity behind a single interface

From a user’s perspective — whether a traveller or a travel agent — the flight booking process seems straightforward, involving just a few obvious operations: search, choose an option, and pay. When everything works as expected, a confirmation email lands in the traveller’s inbox within minutes.

However, under the hood, the end-to-end booking flow consists of multiple internal steps  — or basically, request-response transactions. For instance, creating a reservation (a passenger name record or PNR) with a GDS after the option is chosen involves several API calls:

• verifying the price shown in the search results;
• adding passenger information;
• adding the TST (Transitional Stored Ticket)  — essentially, a pricing record that holds all fare and tax information required for ticketing.

Besides the fact that the flight booking flow is inherently complex, the number and order of the steps may vary across different channels, systems, and airline partners. A unified API abstracts all of that away, allowing the client to work with one consistent request.

“You simply say: I need to book tickets for these passengers (specify the passengers) on these flights (specify the routes, times, and flight numbers). The API already knows how to handle all the necessary calls and goes through the entire flow,” Andrey explains. “From the client’s side, it’s extremely simple — just one request, with all fields clearly defined. Meanwhile, the API takes care of the more tedious work required by the GDS or other channel.”

Even though the goal was to unify as much as possible, complete consistency isn’t achievable, particularly when diverse B2B payment methods are involved — from BSP cash to prepaid accounts and virtual credit cards.

Also, some flight vendors have separate endpoints for booking and ticketing, which aligns with the traditional flow where there is a delay between creating a reservation and making a payment. This is particularly important for travel management companies (TMCs), as corporate bookings often require managerial approval before the purchase is completed.

However,  when it comes to LCCs, booking and ticketing are typically merged into a single step. In NDC flows, both options are possible: an order can be created with or without instant payment. Whether an airline supports one or both scenarios depends on its NDC implementation.

Anyway, the unified API must consider both possibilities, and this will also be reflected in the UI. “ If booking and ticketing happen together, the user immediately sees the ticket number. If they are separate, then after the reservation is confirmed, the user will have an additional step — payment and ticketing,” Andrey says.

Standardized data: making systems speak the same language 

Even when systems perform the same task (in our case, air shopping), they may support different response structures — meaning they use different field names, terminology, or ordering of elements.

For example, one airline might return baggage information under a field called “bagsAllowance”, while another uses “baggageInfo” or spreads the data across several fields. For fare rules, some carriers provide a single “fareConditions” block, while others separate it into fields such as “cancellationPolicy” and “changePolicy.”

This is why the aggregation hub includes a normalization layer that transforms all incoming data into a shared, predictable model with consistent names and structure. Some fields are optional. For instance, Amadeus and Sabre return the number of seats available, while Alp does not — so for Alp offers, this field simply isn’t shown in the user interface. The same applies to carbon offset information: not all carriers provide it, so it appears only when available.

One of the biggest challenges for the team has been normalizing ancillary data, especially paid baggage. “From the response, it’s not always clear what should be treated as the first checked bag, what should be the second, or what the correct price is. So we have to figure out which baggage rules should be applied and automate the flow on a case-by-case basis.” Andrey says. “But the level of automation is far from 100 percent — many things still have to be handled manually by agents.”

The response format that we created may need to be modified from time to time. For maximum customer convenience, the team designed API response models so that they can be extended without breaking backward compatibility. According to Andrey, “When we plan to remove something, we set a deadline — for example, six months — and notify customers that the field will be deprecated. This gives them enough time to adjust and stop relying on the older part of the API contract.”

Overall, unification greatly simplifies things for customers. Since all suppliers return data in the same place and format, adding a new supplier requires minimal effort — they can reuse almost everything they already have.

What can be improved?

As mentioned, the level of booking automation is still far from 100 percent — and this applies not only to paid baggage. For example, a traveler may choose a fare that becomes unavailable by the time they proceed to payment. In such cases, an agent must step in to resolve the issue. However, this process can be automated by having the system proactively offer the traveler a similar flight at a slightly higher price.

Many post-booking steps — such as changing flight dates in the reservation — are also handled manually by travel agents. “This and many other operations could be automated or at least made much easier for agents, so they don't waste time on routine tasks and can focus on things that really require human attention,” Andrey concludes.