Connecting to an airline through NDC can give travel sellers access to more direct airline content and modern retailing capabilities. But connecting to one airline is very different from connecting to many.
Every airline can implement NDC differently. Message structures, schema versions, offer attributes, ancillary services and post-booking capabilities can vary from one carrier to another.
For an OTA, TMC or travel technology platform, managing these differences individually can quickly become complex.
This is where normalisation becomes an important part of NDC aggregation.
Connecting Airlines Is Only the First Step
At its simplest, an NDC aggregator provides connectivity between multiple airlines and travel sellers.
Instead of establishing and maintaining an individual integration with every airline, a seller can connect to an aggregation platform that brings multiple airline connections together.
But connectivity alone does not necessarily create a consistent integration.
Consider a travel platform connecting directly to several airlines.
One airline may return baggage information in one structure, while another represents it differently. Ancillary services may follow different workflows. Offer identifiers, fare details and order-management processes can also vary.
The travel platform would need to understand and accommodate these differences within its own application.
As the number of airline connections grows, so does the integration complexity.
What Is Normalisation?
Normalisation is the process of translating different airline messages and structures into a more consistent format that can be consumed by the travel seller.
A simplified model looks like this:
Multiple Airline APIs → Aggregation & Normalisation → Unified API → Travel Seller
The aggregation layer communicates with the individual airline systems while presenting a more consistent interface to the seller.
For example, different airlines may describe similar information—such as baggage allowance, cabin class or ancillary services—in different ways.
Rather than requiring the seller's application to build separate logic for each source, the normalisation layer can map relevant information into a common structure.
This allows the seller to focus on integrating with a unified API rather than repeatedly adapting its application for every airline connection.
Why Is Normalisation Important?
The benefit becomes clearer as airline coverage expands.
Without normalisation, adding another airline may mean implementing another set of message structures, business rules and workflows.
With an aggregation and normalisation layer, much of that source-specific complexity can be managed behind a common interface.
This can provide several practical advantages.
A More Consistent Integration
Developers can work with a common API structure across multiple supported airline connections instead of creating a completely separate integration for each carrier.
Faster Expansion of Airline Content
When the underlying platform adds supported airline connections, travel sellers may be able to access additional content without developing every connection independently.
The exact onboarding and activation requirements will still depend on the airline and commercial arrangements.
Reduced Integration Complexity
Airline-specific differences can be handled within the aggregation layer, reducing the amount of source-specific logic required in the seller's application.
Easier Application Development
A consistent structure makes it easier for booking applications to consume content from multiple sources and present it through B2C, B2B, corporate or agent-facing interfaces.
Normalisation Does Not Mean Making Every Airline Identical
This is an important distinction.
Normalisation should not remove the characteristics that make an airline's offer unique.
Airlines may provide different branded fares, bundles, baggage allowances, seats, ancillary products and servicing capabilities. These differences are an important part of modern airline retailing.
The role of normalisation is therefore not to make every airline product the same.
Instead, it provides a consistent technical framework while preserving relevant airline-specific information and capabilities.
A well-designed aggregation layer needs to balance both requirements:
Consistency for the travel seller and differentiation for the airline.
What About Post-Booking Servicing?
Normalisation becomes particularly important after a booking has been created.
As discussed in our previous Insight on NDC order management, airlines may support different servicing capabilities.
One carrier may allow a particular change through its API while another may use a different workflow or may not support that action digitally.
An aggregation platform therefore needs to do more than normalise search results.
It must also account for differences throughout the booking lifecycle, including supported processes such as:
- pricing and offer confirmation;
- booking and fulfilment;
- order retrieval;
- ancillary servicing;
- changes and reshopping;
- cancellation; and
- refunds.
The capabilities available ultimately depend on each airline's implementation, seller entitlement and applicable commercial conditions.
A Unified API as an Abstraction Layer
For developers, a unified airline API acts as an abstraction layer between the travel application and multiple underlying airline systems.
Instead of the application communicating directly with every source, the unified API becomes the primary integration point.
Airlines → Unified Integration Layer → Travel Application → Traveller
This architecture can make it easier to expand airline content while keeping the seller's application relatively consistent.
It can also allow the aggregation platform to manage changes to individual airline integrations without requiring every connected travel seller to rebuild its entire integration.
What Should Travel Sellers Evaluate?
When evaluating an NDC aggregation platform, airline coverage is important—but it should not be the only consideration.
Travel sellers should also understand:
- how different airline responses are normalised;
- whether important airline-specific content is preserved;
- which shopping and servicing workflows are supported;
- how API changes are managed;
- how new airline connections become available; and
- whether the same integration can support the broader booking lifecycle.
These considerations help determine whether an aggregation platform is simply providing connectivity or creating a scalable foundation for airline retailing.
Building for Scale
As airline distribution continues to evolve, travel sellers are increasingly working with content from multiple sources.
Managing each connection independently can create technical and operational complexity.
Aggregation helps bring those connections together. Normalisation makes them easier to consume consistently.
Together, they can provide a foundation that allows travel businesses to expand airline connectivity without continually redesigning their applications around every individual source.
At Pratra, our approach to airline connectivity is built around this principle: connect different airline content sources, manage their underlying differences and expose supported capabilities through unified technology.
Because connecting more airlines should not mean creating more complexity.
