Ready to Launch Your Travel Platform?
Join 150+ travel businesses already managing bookings, distribution, and accounting with TourX. Configure your package and get custom pricing tailored to your operations.
Airline content distribution has become a tangled web of technology providers. GDSs like Amadeus, Sabre, and Travelport. NDC aggregators like Travelfusion and Duffel. Direct airline APIs. Third-party platforms. Each channel uses its own standards, formats, and implementation logic.
For TMCs and OTAs that must pull content from all of them, the result is inherent inconsistency — fragmented data that’s difficult to unify without purpose-built normalization solutions.
At TourX, we’ve encountered air content discrepancy issues across projects with OTAs, TMCs, and flight aggregators. This article, drawn from that hands-on experience, breaks down where and why things go wrong in real-world airline content integration — and explores practical ways to bring order to the chaos.
Three Content Sources, Three Sets of Problems
GDS and EDIFACT: Rigid but Reliable
The connection between airline reservation systems and GDSs runs on EDIFACT, a legacy messaging protocol built on structured text. It’s rigid by design. Core attributes like fare references, seat availability, and baggage allowances follow predefined formats and standardized fields. That makes the data predictable across airlines but limits what can be expressed.
EDIFACT was never designed for modern merchandising. While OTAs and TMCs don’t consume EDIFACT messages directly, the constraints carry through. Branded fares, rich ancillary descriptions, and bundled offers don’t translate well through this channel.
NDC: Flexible but Fragmented
NDC, introduced by IATA in 2012, uses XML schemas built for web-based distribution. It was designed to let airlines sell through third parties in a way that mirrors their own websites — supporting rich content like images, text descriptions, bundled offers, and a wider range of ancillary products.
But here’s the catch: NDC defines message structures and flows without strictly enforcing how content or business logic should be modeled. Every airline implements it differently.
Low-Cost Carriers: Independent by Nature
LCCs have historically focused on direct distribution. They’ve built their APIs independently of industry standards, typically using REST/JSON — a lighter, more modern format compared to XML. As low-cost carriers increasingly integrate with aggregators like Kiwi.com or Duffel, or establish direct API connections with large agencies, their content enters the same platforms as NDC and GDS data.
Three fundamentally different content sources naturally produce inconsistencies. And within NDC itself, the variation from airline to airline only compounds the problem.
Why NDC Doesn’t Work as a True Standard
Although NDC is commonly called a standard, in practice it functions more like a flexible framework. Structurally, it provides a common foundation — but it doesn’t enforce the consistency that the word “standard” implies.
The main divide in modern airline distribution is no longer between EDIFACT and NDC — it’s between NDC airlines themselves.
The inconsistency plays out across several layers.
Schema Interpretation Varies Wildly
A substantial gap often exists between what the IATA specification describes and what airlines actually implement. One carrier might return all fare families and bundles in an initial shopping response. Another requires additional calls — sometimes non-obvious ones — to retrieve the same information. What should be a straightforward shopping flow becomes unpredictable.
Version Proliferation Creates Complexity
More than ten NDC schema versions are in active use simultaneously. Airlines rarely migrate cleanly from one to the next. Instead, many adopt a hybrid approach — shopping and booking may run on newer versions (like 21.3 or 24.1), while servicing endpoints remain on older ones (like 17.2), with an order management system bridging the gaps.
This creates inconsistencies not just between airlines but within a single carrier’s own technology stack.
Implementation Depth Is Uneven
Some carriers support the full booking and servicing lifecycle through NDC. Others expose only partial functionality. The same operation — a seat change, a refund request, adding an ancillary — may work seamlessly with one airline and fail entirely with another, even though both are technically NDC-enabled.
Converting Chaos to Order: The Normalization Architecture
The industry players dealing with these discrepancies — flight aggregators, large OTAs, and TMCs integrating directly with airlines — must absorb the complexity of mixed sources and formats.
To present air offers consistently, they unify various APIs through a normalization layer. This typically includes three components: a canonical data model, mapping logic, and adapter layers. In most implementations, the resulting data is exposed via a unified internal API.
Component 1: A Canonical Data Model Built Around User Needs
When integrating multiple airlines, one tempting approach is to take the latest NDC schema as a reference point and map everything — older NDC versions and EDIFACT content — into that structure. In practice, this breaks down quickly. NDC versions evolve constantly, and anchoring your architecture to an external specification means perpetual rework.
The better approach starts from the opposite direction: user needs. You design an internal canonical model that defines how offers should appear within the system, independent of any external format.
This model typically includes core entities like fare attributes, baggage allowances, seat options, and change/cancellation rules, along with additional fields to preserve flexibility. The goal is to abstract away format-specific differences while still capturing the full range of airline content.
Depending on the use case, the model may lean toward an NDC-style structure — organizing content around offers and orders — or a more rigid, field-based structure similar to EDIFACT, where attributes are clearly defined and consistently organized.
Crucially, the model must account for missing data. Not every airline supports the same features, and the system needs to handle those gaps gracefully. If one airline doesn’t support seat selection, the UI should clearly communicate that rather than silently dropping the option. The same applies to post-booking services like changes, refunds, or ancillary add-ons — when they aren’t available via API, the system should direct the traveler to contact an agent.
Component 2: Mapping and Adapters for Airline-Specific Translation
Mapping defines how airline-specific attributes correspond to the internal model. For example, an airline’s branded fare name or service label needs to align with a standardized concept in the system. Simple cases can be handled through lookup tables, though more complex mappings often require transformation logic.
Each airline (or group of similar integrations) is handled through an adapter layer. Adapters transform incoming data into the canonical model, and the translation works in both directions:
Inbound: airline response → canonical model (for search and display)
Outbound: canonical model → airline format (for booking and servicing)
While adapters can share some logic — particularly when airlines use similar NDC versions — they still require per-integration configuration and customization. And as carriers evolve their implementations, adapters must evolve alongside them. Airlines that regularly migrate to new schema versions need to be tracked in the product backlog.
Component 3: Business Logic for Content Selection
Once a canonical model is in place, the system needs rules for deciding what content to show when multiple sources overlap.
If the same fare is available through both EDIFACT and NDC, the system may prioritize NDC for richer content. If the content is equivalent but prices differ, the cheaper option wins. More complex scenarios arise when prices match but conditions differ — baggage allowance, flexibility rules, change fees. In these cases, there’s no universal answer, and the logic must be tailored to what the platform values.
Does NGS Solve the Problem?
In 2019, ATPCO (the centralized aggregator of airline fares, rules, and pricing logic) introduced the Next Generation Storefront (NGS) — a data standard designed to harmonize the consumer shopping experience.
NGS shifts the display paradigm from “price and schedule” to a value-based grid with “shelves” and “drawers.”
Shelves are six standardized columns that categorize fares by value rather than brand name. Instead of seeing cryptic fare names like “Y-FLEX” or “Saver Plus,” travelers see functional categories like “Basic Economy” or “Economy Extra.” Offers are grouped based on 18 specific attributes — seat pitch, baggage allowance, ticket changeability, and more.
Drawers are expandable sections within each shelf where travelers can compare granular details like Wi-Fi availability, power outlets, or meal service. This enables genuine apples-to-apples comparison across airlines.
It’s an elegant display framework. But NGS is just the shelf layout — it depends entirely on the quality of data coming in. If an airline sends a cryptic code instead of a clear attribute, NGS logic can’t determine where to place that offer.
Think of NGS as the shelf layout in a supermarket. It makes shopping easier for customers. But normalization is the logistics team working behind the scenes — unloading trucks, removing incorrect labels, and ensuring price tags are accurate so the shelves stay clean and organized.
Common Air Content Issues You’ll Encounter
Mismatches in how different suppliers model, return, and interpret the same concepts tend to cluster into recurring problem areas. Here are the most common ones we’ve seen at TourX while building flight aggregation platforms.
Baggage: The Messiest Data in Air Content
Baggage is one of the least reliable parts of airline content. Airlines and GDSs don’t always clearly indicate whether a baggage entry refers to checked bags, carry-ons, or personal items, or how allowances (first vs. second bag) should be interpreted.
This is frustrating because standardized codes already exist. ATPCO introduced three-digit RFISC codes years ago — 0CC for first checked bag, 0CD for second, 0B1 for prepaid baggage, 0DG for carry-on. IATA has also created a retail-oriented taxonomy used in NDC that provides higher-level classification.
In practice, adoption is uneven. Some airlines rely on their own proprietary codes. Others return partially structured or fully unstructured descriptions. The complexity increases further in interline itineraries, where different segments may follow different baggage rules.
GDSs don’t fully resolve these inconsistencies. They may return a human-readable string like “no checked baggage and two carry-on items” — which then has to be parsed.
Practical solution: Use lookup tables for known airline codes and text parsing for everything else. Regular expressions can extract structured data from free-text descriptions. Normalization ultimately remains case-specific — if full unification isn’t possible, handle edge cases individually.
Flight Attributes: Filling the Gaps
Not all suppliers return complete flight information, yet travelers expect it. One common gap: missing flight duration data, even though passengers rely on it to plan their time, meals, and connections.
Practical solution: Maintain a custom database of airport time zones. This lets you calculate flight duration accurately even when the supplier doesn’t provide it.
Fare Conditions: Information Overload
Penalty data for changes and refunds often comes across as a wall of scenarios — before departure, after departure, no-show — without clear prioritization or context. Travelers don’t need all of that. They mainly want to know: how much will it cost to cancel or change a ticketed flight before departure?
Practical solution: Filter, reorganize, and map raw penalty data into user-relevant categories like “change” and “cancel.” Translate supplier logic into user intent.
Observability: You Can’t Fix What You Can’t See
Diagnosing inconsistencies is itself a challenge. Supplier responses often lack transparency, making it difficult to understand failure patterns or performance issues without purpose-built tooling.
Practical solution: Build custom observability layers to track route performance, error rates, and supplier-specific anomalies. Operational visibility isn’t optional — it’s a prerequisite for effective normalization.
Where AI Fits Into the Picture
AI won’t replace the need for solid architectural foundations, but it’s increasingly handling the heavy lifting of air content sorting, routing, and translation.
Accelerating adapter development. As airlines roll out new NDC versions, developers often spend months building and maintaining adapters. AI can analyze provider documentation to identify response schemas, field structures, and business rules — significantly speeding up this process, though human validation remains essential.
Intelligent field mapping. AI can help determine how new data structures fit into an existing canonical model. It can suggest transformations for field names and formats — ensuring that a “Deluxe Bag” from one airline maps consistently to a standard checked baggage attribute in the canonical model.
Classification of unstructured content. This is where AI really shines. Processing marketing fare names, unstructured service descriptions, and inconsistent labels is a classification problem. Machine learning models can accurately determine which category a fare belongs to when a supplier hasn’t labeled it consistently — turning messy text into structured, actionable data.
The Bottom Line
Air content normalization isn’t a one-time project. It’s an ongoing discipline. Airlines evolve their implementations. New NDC versions appear. LCCs join aggregation platforms. GDS content shifts.
The organizations that handle this well share a few traits: they design canonical models around user needs rather than external specifications, they build adapter architectures that can evolve alongside suppliers, and they invest in observability to catch problems before they reach travelers.
AI is making the process faster and more scalable, but the fundamentals remain the same. Clean architecture, thoughtful mapping, and relentless attention to edge cases are what separate platforms that merely aggregate flights from those that deliver a genuinely consistent booking experience.
TourX helps OTAs, TMCs, and flight aggregators solve air content integration challenges. From normalization architecture to adapter development, we build the systems that turn fragmented airline data into unified, bookable content.