Here is something every travel agent and agency owner running a booking portal already knows, even if they have not put it into words yet: the GDS alone does not show you everything.
Amadeus, Sabre, and Travelport together handle over 97 percent of all GDS-based travel bookings globally. That sounds comprehensive, and for full-service carrier content, it largely is. But travel distribution in 2026 does not live entirely inside the GDS. It never did for low-cost carriers, and it increasingly does not for full-service carriers either.
Consider what sits outside the traditional GDS channel right now. Low-cost carriers like Ryanair, IndiGo, AirAsia, SpiceJet, and Wizz Air either distribute very limited content through GDS systems or none at all. These airlines sell primarily through their own websites and through direct API connections with platforms that have integrated their specific APIs. If your travel portal is GDS-only, you cannot book these carriers at all.
Then there is the NDC shift happening across full-service carriers. Airlines, including Lufthansa, Air France, British Airways, American Airlines, and United Airlines, now publish their best fares, their branded fare bundles, and their ancillary offers exclusively or preferentially through NDC channels rather than through the traditional EDIFACT-based GDS channel. A GDS-only platform that has not added NDC connectivity is showing its customers a subset of the fares those carriers actually offer.
And then there are direct airline APIs. Emirates, Singapore Airlines, Qatar Airways, and many other carriers have developed their own direct booking APIs that allow travel platforms to connect to them outside the GDS entirely, often at lower distribution cost and with access to content that is not available through indirect channels. A platform that can connect to these direct APIs alongside its Amadeus GDS connection gets content advantages that its GDS-only competitors simply cannot match.
The solution is not to abandon Amadeus. Amadeus remains the most capable GDS available for international flight content, covering over 900 airlines across 190 markets and carrying the strongest NDC adoption of any GDS with 35 NDC airline partnerships. The solution is to use Amadeus as the content foundation and build an aggregation layer on top of it that pulls in direct airline APIs, LCC feeds, and NDC channels alongside the GDS content. That is what airline API aggregation delivers.
Before getting into how aggregation works technically, it helps to understand the four distinct types of airline content that a properly built platform can access. Each type has its own distribution mechanism, its own strengths, and its own integration requirements.
Content Type | What It Is | Examples | Key Strengths | Limitation |
|---|---|---|---|---|
GDS Content | Fares filed through Amadeus, Sabre, or Travelport via the traditional EDIFACT channel | Most full-service carriers, regional airlines | Single integration gives access to hundreds of carriers, mature ticketing workflows | LCCs are largely absent, and some airline content is behind NDC only |
NDC Content | Fares and offers distributed via IATA's XML-based New Distribution Capability standard | Lufthansa, Air France, British Airways, American Airlines, United Airlines | Richer fare bundles, personalised offers, and ancillaries not available via EDIFACT | Requires NDC-specific integration; not all carriers support it |
Direct Airline API | A proprietary API published by an individual airline for direct connectivity outside GDS | Emirates, Qatar Airways, Singapore Airlines, IndiGo | Lower distribution cost, airline-specific fares, sometimes exclusive content | Separate integration per airline, varied API quality, and documentation |
LCC API | A specific API for low-cost carriers that do not distribute via traditional GDS | Ryanair, AirAsia, Wizz Air, SpiceJet, Flybondi | Access to fares that GDS cannot show at all | Each LCC has its own API format, no standard protocol, high integration effort per carrier |
A portal that accesses only one of these content types is leaving a meaningful portion of available flights off its results pages. A portal that accesses all four is showing its customers the most complete picture of available flights on any given route. That is the competitive advantage that well-executed direct airline API integration delivers when combined with Amadeus GDS coverage.
The technical architecture of an aggregated airline content platform is not as complex as it might sound, but it does require careful design decisions at each layer. Here is how the major components fit together.
Amadeus sits at the core of the content stack for good reason. Its API catalog is one of the most mature in the industry, covering flight search and pricing through the Flight Offers Search API, fare confirmation through the Flight Offers Price API, booking creation through the Flight Create Orders API, seat selection through the SeatMaps API, and NDC content through its 35 airline NDC partnerships. The Amadeus Self-Service APIs are available through a developer sandbox immediately, and the Enterprise APIs are available through a commercial agreement for higher-volume platforms.
Starting with Amadeus as the foundation gives you a solid base of content covering over 900 airlines, with the NDC layer built in from the start. Flight Terminus's Amadeus GDS integration service builds this foundation and then extends it with the additional content layers described below.
On top of the Amadeus foundation, direct airline APIs are connected for carriers where a direct connection provides content advantages over the GDS channel. Emirates, Qatar Airways, and Singapore Airlines, for example, all publish direct APIs that allow platforms to access fares, availability, and ancillaries directly from the airline's own systems. The direct connection typically carries lower per-booking distribution costs than the GDS channel and may provide access to exclusive fares or promotional content that the airline does not make available through indirect channels.
Each direct airline API connection is a bespoke integration because every airline publishes its API differently, with its own authentication approach, its own data schemas, its own booking flow, and its own ticketing requirements. The aggregation layer normalises the data coming from each direct API into a common format that the platform's front-end can display consistently alongside GDS fares. Flight Terminus's integration service covers this normalisation work as part of every direct airline API project.
Low-cost carriers are where the content gap between GDS-only platforms and aggregated platforms is most visible. Ryanair, AirAsia, IndiGo, Wizz Air, SpiceJet, Flybondi, and many other LCCs sell the majority of their seats directly or through platforms that have integrated their specific APIs. Some of these carriers distribute a portion of their content through GDS or through aggregators like Amadeus Altéa, but many routes and fare types are only available through the carrier's own distribution channel.
Connecting LCC APIs requires integrating each carrier individually. The technical effort per carrier varies significantly because LCCs do not follow a single common API standard. Some use XML-based interfaces, some use REST, some use SOAP-based legacy protocols. The aggregation layer handles the protocol translation and data normalisation so that an IndiGo fare in the results looks structurally identical to an Air India fare, even though they came from completely different source systems.
Flight Terminus's AQC flight API integration solution provides a structured approach to connecting LCC and direct airline content alongside GDS inventory, significantly reducing the per-carrier integration effort compared to building each connection from scratch.
The aggregation engine is the component that ties all content sources together. When a customer searches for a flight, the engine fires simultaneous queries to each connected content source, collects the responses, and processes them through three critical functions.
Deduplication removes duplicate results that appear across multiple sources. When the same Emirates flight appears in both the Amadeus GDS results and the Emirates direct API results, the engine compares flight number, departure time, arrival time, fare class, and carrier before selecting the best-priced version to display.
Normalisation converts data from each source into a common format. A fare returned by Ryanair's API looks structurally different from a fare returned by Amadeus. The normalisation layer translates both into the same data schema, so the platform's front end displays them consistently.
Source tagging tracks which content source each fare in the results came from, so that when a customer selects a fare and proceeds to book, the booking request is routed back to the correct source system for PNR creation and ticketing.
Each booking must be confirmed through the source system from which the fare originated. An Amadeus-sourced fare gets booked through the Amadeus Flight Create Orders API. A direct airline API fare gets booked through that airline's own booking endpoint. An LCC fare gets booked through the LCC's own reservation system. The booking router maintains source references throughout the session and directs each booking request to the correct back-end system without the agent or customer needing to know which system is handling it.
One of the most practical questions agencies ask about airline API aggregation is which specific carriers become accessible that were not available through GDS alone. The answer depends on your specific GDS configuration and which direct and LCC connections you add, but here is the general picture.
Carrier Category | Access via Amadeus GDS | Access via Direct API | Access via LCC API | Notes |
|---|---|---|---|---|
Full-service international carriers (Air France, Lufthansa, BA, etc.) | Yes, EDIFACT fares | Yes, NDC content via direct connection | Not applicable | Best fares often through NDC, not EDIFACT GDS |
Middle East full-service carriers (Emirates, Qatar, Etihad) | Yes, most content | Yes, Emirates and Qatar have direct APIs | Not applicable | Direct APIs often give ancillary content that GDS lacks |
Indian LCCs (IndiGo, SpiceJet, Air India Express) | IndiGo partial via Amadeus | Yes, direct API available | Yes, IndiGo and SpiceJet LCC APIs | GDS coverage for Indian LCCs is incomplete |
European LCCs (Ryanair, Wizz Air, easyJet) | Very limited or none | Partial, Ryanair is restrictive | Yes, each has its own API | Ryanair does not distribute through GDS at all |
Southeast Asia LCCs (AirAsia, Scoot, Batik Air) | Limited via Amadeus | Yes, AirAsia has a direct API | Yes | AirAsia content is significantly better via direct |
US budget carriers (Frontier, Spirit, Allegiant) | Limited | Yes, via direct connections | Yes, Spirit and Frontier have APIs | These carriers are US-domestic focused |
Charter and consolidator content | Partial | Some charter operators have direct APIs | Not applicable | Requires separate consolidator connections |
The table above illustrates why a single Amadeus GDS connection, powerful as it is, leaves gaps in the content available to your platform. Adding direct airline APIs and LCC connections fills those gaps and gives your platform the ability to serve customers on routes and with carriers that GDS-only competitors cannot touch.
Building an aggregated airline content portal is not just about connecting multiple APIs. The features of the platform built on top of those connections determine whether the aggregation actually delivers value to your agents and customers.
The agent or customer enters their search once. The platform queries all connected content sources simultaneously and returns a single unified list of results. GDS fares, NDC offers, direct airline fares, and LCC prices appear in the same results page, sorted by price, duration, or the agent's preferred ranking criteria. The source of each fare is visible to agents in the back end for transparency, but the customer-facing display shows a clean, unified search experience.
When the same flight appears from multiple content sources at different prices, the platform displays it once at the best available price. The deduplication logic compares on flight number, operating carrier, departure and arrival times, and fare class before treating two results as the same flight. A portal that displays the same flight twice at different prices from different sources creates confusion and erodes customer confidence immediately.
Different content sources carry different commission structures, distribution costs, and margin profiles. Your platform's admin layer should allow you to configure different markup rules per content source, per carrier, per route, or per fare class. A direct airline API connection that carries lower distribution costs can be marked up differently than a GDS-sourced fare to protect margin while still showing competitive pricing. This level of control is built into the Flight Terminus custom B2B flight booking solution and B2C portal frameworks.
Direct airline APIs and NDC channels typically carry richer ancillary content than the traditional GDS channel. Seat selection, baggage options, meal preferences, lounge access, priority boarding, and fast-track security can often be offered within the booking flow when the content comes from a direct or NDC source, where the same content from a GDS-only connection would show a bare fare with no ancillaries. Your aggregation platform should surface ancillary options when the source content provides them, adding upsell revenue to every booking that supports it.
Fares from any source can change between the moment a customer selects them and the moment the booking is confirmed. Your platform needs a fare verification step that re-prices the selected itinerary against the originating source system in real time before taking payment. This is standard practice for GDS bookings but equally important for direct airline and LCC connections, where inventory can change rapidly, especially on high-demand routes.
An agent managing bookings sourced from Amadeus, from a direct Emirates connection, and from an IndiGo LCC API needs to see all of those bookings in one consolidated view. The PNR management dashboard should show every booking regardless of its source, with full passenger details, ticketing status, and any post-booking actions required. Without this consolidation, agents end up managing separate systems for each content source, defeating much of the operational benefit the aggregation layer was designed to deliver.
Firing simultaneous API queries to multiple content sources on every search creates two pressures: latency and cost. A well-built aggregation platform implements intelligent caching at the route and fare class level, storing recent search results for a configurable time window and serving those cached results for repeat queries while refreshing them in the background. This reduces API call volumes, cuts per-transaction costs, and significantly improves search response times for common route queries.
Building a multi-GDS portal is a more substantial technical project than a single-GDS integration. Here is an honest breakdown of what the development process involves and what the major decisions are at each stage.
Before any development begins, you need active API credentials for each GDS you plan to connect. Amadeus Self-Service APIs are available through the Amadeus for Developers portal and provide sandbox access immediately. Amadeus Enterprise credentials require a formal commercial agreement and are negotiated based on your booking volumes and market. Sabre and Travelport operate similarly: developer sandbox access is available relatively quickly, while production access requires a contracted relationship. Flight Terminus can facilitate introductions to GDS account teams as part of the project scope.
Before writing code, the architecture needs to be designed: which GDS sources the portal connects to, which routes are served by which primary GDS source, how the aggregation and deduplication logic works, and how the booking routing is handled. This stage also covers which NDC channels are included, whether direct airline APIs are required for specific LCC content, and how the caching layer is structured to manage API costs and response times.
The backend development connects to each GDS API, implements the aggregation, normalisation, deduplication, and routing logic, and builds the booking and ticketing flow. For a multi-GDS portal, this is the most complex and time-consuming development phase. Amadeus REST APIs are the most developer-friendly of the three major GDS systems to work with, which is another practical advantage of using Amadeus as the primary integration layer. Sabre and Travelport both use more complex XML and SOAP-based protocols for their core booking functions.
The front-end search interface, results display, booking flow, payment integration, and agent management tools are built on top of the backend layer. For agencies wanting a B2C portal, Flight Terminus's B2C flight booking portal framework provides a production-tested front-end foundation that significantly reduces the front-end build timeline. For B2B portals serving travel agents, the custom B2B flight booking solution framework handles agent login, markup configuration, and PNR management out of the box.
Every GDS provides a sandbox environment for testing before production access. Multi-GDS testing is more complex than single-GDS testing because you are testing the interaction between multiple API sources, not just one. The deduplication logic, routing rules, and fare normalisation all need to be validated with real data from each GDS sandbox before any production credentials are used. Expect a thorough QA phase covering all major booking flows, edge cases, and error scenarios across each GDS source.
After sandbox testing, the portal moves to production with live GDS credentials. The first weeks in production require careful monitoring of API response times, error rates, and deduplication accuracy across real bookings. API cost monitoring is also important from day one, as multi-GDS search volumes can generate significant per-transaction costs that need to be managed against the routing and caching logic configured during development.
Amadeus Quick Connect, commonly referred to as AQC, is Amadeus's own mechanism for connecting additional airline content sources to a platform that already uses Amadeus as its primary GDS. Rather than building completely separate integrations for each direct airline or LCC, AQC provides a structured framework for bringing non-GDS content into the Amadeus environment.
For travel businesses that are already building on Amadeus, AQC is worth understanding as part of the broader aggregation strategy. It allows the Amadeus platform to distribute content from airlines that use it specifically for their LCC distribution, including carriers that have configured the Amadeus connection for light-ticketing or e-ticketing without going through the traditional EDIFACT GDS channel. Some airlines with no conventional GDS presence can still be booked through Amadeus using this mechanism.
Flight Terminus's AQC flight API integration solution covers this capability as a specific service for platforms that want to extend their Amadeus-based content coverage using the AQC framework rather than building standalone direct airline integrations for every individual carrier.
Not every travel business has the same content coverage requirements. Here is how the need for aggregated airline API content maps to different business types.
Travel markets like India, Southeast Asia, and Europe have significant portions of air travel served by LCCs that distribute little or no content through GDS. An OTA in India that can only show Air India and Vistara through Amadeus GDS but cannot show IndiGo, SpiceJet, Air India Express, or GoAir on domestic routes is not competitive on those routes. A B2C flight booking portal in those markets needs LCC API connections to be viable, not just aspirational.
Corporate clients book a wide range of airlines, including LCCs for domestic legs, full-service carriers for international travel, and sometimes specific airlines for loyalty program reasons. A custom B2B flight booking solution for corporate travel that cannot show LCC options on relevant routes forces corporate travelers to use a separate booking channel for those carriers, undermining the entire purpose of having a consolidated booking tool.
Travel aggregators whose downstream clients are smaller agencies or white label portal operators need the broadest possible content coverage because they cannot predict which specific carriers their downstream clients will need to book. An aggregator whose content coverage has gaps will have sub-agents looking elsewhere for the carriers that gap excludes. The travel aggregator portal development service from Flight Terminus is designed around exactly this requirement.
A travel business focused on pilgrimage travel needs to book Saudia, Flynas, and flyadeal alongside Air India Express and IndiGo for India-Saudi Arabia routes. A sports travel business needs access to charter and seasonal carrier content alongside GDS fares. A tour operator in Southeast Asia needs AirAsia and Scoot alongside Singapore Airlines and Thai Airways. Each of these businesses has specific carrier coverage requirements that a GDS-only platform cannot fulfil but an aggregated platform can.
Understanding what to expect during the build helps agencies plan their project correctly and set realistic timelines. Here is how Flight Terminus approaches an aggregated airline API project from start to production.
The first step is understanding which content sources your platform actually needs, based on the routes you serve, the carriers your clients book, and the markets you operate in. Not every platform needs every LCC connected from day one. The content map defines which direct airline APIs add genuine coverage value over the Amadeus GDS base and which LCC connections are most commercially important for your specific booking patterns.
The Amadeus GDS layer is built first because it provides the largest single block of content with the best-documented and most developer-friendly APIs in the industry. This covers the full Amadeus API stack from flight search and pricing through booking and ticketing. See the full Amadeus API catalog for the complete range of available endpoints. The Amadeus layer is the stable foundation that the additional direct and LCC connections are then layered onto.
Each direct airline and LCC connection is built individually because each carrier has its own API format and documentation. The integration work per carrier covers API authentication, flight search query construction, response parsing, data normalisation into the common schema, and booking flow implementation. The aggregation and deduplication logic is then extended to handle content from each new source alongside the Amadeus GDS results.
NDC connections for carriers that distribute their best content through NDC rather than EDIFACT are added as a specific integration workstream, using either the Amadeus NDC framework for airlines where Amadeus is the NDC aggregator, or direct NDC connections for airlines where a direct NDC relationship is more appropriate. The Amadeus GDS integration service from Flight Terminus covers NDC integration as a standard component of the Amadeus layer.
All content sources are tested in sandbox environments before any production credentials are used. Multi-source testing is more complex than single-source testing because the deduplication logic, normalisation rules, and booking router all need to be validated with real data from every connected source simultaneously. The QA phase covers all major booking flows, edge cases, fare change handling, and error scenarios across every source in the aggregation.
After sandbox testing, the platform moves to production with live API credentials for each connected source. The first weeks in production include monitoring of response times per source, error rates from each API, deduplication accuracy, and API cost per search query. Caching configuration is adjusted in production based on real search patterns rather than assumptions made during development.
Flight Terminus builds custom travel technology platforms for agencies, OTAs, aggregators, and travel businesses that need more content coverage than a single GDS connection provides. Our aggregated airline API service covers the full stack from Amadeus GDS integration through direct airline connections, LCC APIs, and NDC content.
Every project starts with a discovery session to understand your content requirements, your markets, and your booking volumes. To start that conversation, contact the Flight Terminus team at flightterminus.com/contact-us.
The information in this guide is drawn from direct experience building flight content aggregation platforms for travel agencies, OTAs, and aggregators across India, the Middle East, and Southeast Asia. The specific API behaviors, carrier distribution patterns, and technical architecture described here reflect real projects built and maintained in production, not theoretical specifications from documentation alone.
Airline distribution is a fast-moving area. Carrier API terms change. LCCs modify their distribution strategies. NDC adoption continues to expand across more carriers. The practical guidance in this blog reflects the state of these systems as of mid-2026. For the most current information on Amadeus API capabilities, visit amadeus.com/en/airlines/products/all. For platform-specific questions about your aggregation project, contact the Flight Terminus team directly.
Frequently Asked Questions regarding airline API aggregation
Airline API aggregation is the process of connecting a travel booking platform to multiple flight content sources simultaneously, including GDS systems like Amadeus, direct airline APIs, NDC channels, and LCC-specific APIs, and combining their content into a single search result. It matters because no single content source covers all available flight options. GDS systems like Amadeus cover the majority of full-service carrier content but miss most LCC inventory and an increasing proportion of full-service carrier content that is now distributed exclusively through NDC channels. An aggregated platform shows more options, more competitive fares, and gives agents the ability to book carriers that a GDS-only system cannot access.
Some low-cost carriers do distribute through Amadeus, either through the traditional GDS channel, through the Amadeus Light Ticketing and E-Ticketing mechanisms, or through the AQC framework for LCC distribution. Amadeus has partnerships with over 110 LCC and hybrid carriers. However, major LCCs, including Ryanair, Wizz Air, and several large Asian budget carriers, distribute little or no content through Amadeus or any GDS. For those carriers, a direct LCC API connection or an LCC-specific aggregator is required alongside the Amadeus GDS integration.
NDC (New Distribution Capability) is a technical standard developed by IATA that defines how airlines can distribute richer content directly to travel platforms using an XML-based protocol. A direct airline API is simply an API published by an individual airline that allows direct connectivity, which may or may not use the NDC standard. Emirates and Qatar Airways have direct APIs that are proprietary to those carriers. Lufthansa and Air France distribute their NDC content through the NDC standard but via Amadeus or other NDC-certified aggregators rather than through purely proprietary connections. In practice, the distinction matters for integration: NDC integrations can often be built using Amadeus as the NDC aggregator, while truly proprietary direct airline APIs require bespoke integrations per carrier.
The timeline depends on the number of content sources being integrated and the complexity of the platform's front-end. A platform connecting Amadeus GDS plus two or three direct airline or LCC APIs with a standard booking flow typically takes 14 to 20 weeks from project start to production launch. A more comprehensive aggregation platform connecting Amadeus, multiple direct airline APIs, LCC feeds, and NDC channels with a full-featured agent management system typically runs 20 to 30 weeks. The discovery and architecture design phase at the start of the project produces a detailed timeline based on the specific scope.
Direct airline and LCC APIs change over time as carriers update their distribution technology. Each API update can require changes to the integration layer that connects to that carrier's API. This is one of the ongoing maintenance realities of running an aggregated content platform, and it is different from GDS maintenance, where Amadeus manages the connection to hundreds of carriers on your behalf. Flight Terminus provides ongoing API maintenance as part of its post-launch support service, covering GDS version updates, direct airline API changes, and LCC connection updates as they occur.
Yes, and this is a sensible approach for many agencies. Building a strong Amadeus GDS and NDC foundation first, then adding direct airline and LCC connections where coverage gaps are identified, is more practical than trying to connect every possible source from the beginning. The key requirement is that the initial build is architected with extensibility in mind, so that adding new content sources later does not require rebuilding the aggregation engine. Flight Terminus designs every aggregation platform backend with this extensibility requirement built into the architecture from the start.
Without caching, yes, querying multiple APIs simultaneously adds latency compared to a single-source search. With a well-designed caching layer, most of this latency is eliminated for common route queries. The aggregation engine fires queries to all content sources simultaneously (not sequentially) to minimise the wait time, and a caching layer serves recent results for repeat queries while refreshing them in the background. For less common routes where cache coverage is lower, response times are longer, but for high-volume routes where cache hit rates are high, the experience is comparable to a single-source search.
The best starting point is a discovery call with the Flight Terminus team. We review your current platform setup, your content coverage requirements, the specific carriers and routes most important for your business, and your booking volumes. From that conversation, we produce an architecture recommendation and a project scope. You can book that initial conversation at flightterminus.com/contact-us.