NDC API Integration Cost: The Standard That Does Not Standardise

An agency connects its first carrier over NDC. It takes longer than planned but it works, and everyone assumes the hard part is behind them. The second carrier is quoted at a fraction of the first, on the reasoning that the standard has now been implemented.

It comes in at nearly the same number. NDC API integration cost is priced per airline because the variance is per airline, and a published specification turns out to constrain the envelope rather than the contents. Two carriers can both be entirely compliant and still disagree about how an infant is expressed, when a price is guaranteed, what happens to an unused segment, and which errors are recoverable.

What NDC actually changes about a booking

The shift is from a shared inventory abstraction to a conversation with each airline.

In the legacy world a passenger name record holds the itinerary, a separately issued electronic ticket represents the entitlement to travel, and electronic miscellaneous documents cover everything else, which is why an ancillary reconciles down a different path from the fare. That structure is common across carriers because the distribution layer imposed it.

Under NDC the airline responds to a shopping request with an Offer, which is its own construction, priced and bundled as it chooses. Accepting an Offer produces an Order. Under ONE Order that Order is intended to collapse the record, the ticket and the miscellaneous documents into a single unified record of what the passenger is entitled to.

That is a genuine improvement in expressiveness. It is also the source of the cost. When the carrier constructs the offer, the carrier decides its shape, and your system has to accommodate every shape it is given rather than one shape the industry agreed on.

Certification tells you less than it used to

Buyers frequently ask which certification level a carrier holds, expecting it to predict effort. It predicts less than they hope, and the ground has moved.

The familiar framing was a set of levels: shopping, then shopping with order creation, then full order management including changes and cancellations, with further levels added later to indicate deployment at scale. IATA has since moved to the Airline Retailing Maturity index, which replaces that earlier set of certification levels.

Two things are worth taking from this.

The first is that any integration plan built on a remembered level number should be rechecked against what the carrier publishes now, because the vocabulary in circulation is a mixture of the old scheme and the new one, and vendors quote whichever flatters them.

The second matters more for cost. Certification says a carrier can do a category of thing. It does not say how. Two airlines both capable of order change will differ on whether a change is a modification of the existing Order or a cancel and rebook, whether the price is held during the exchange, and what is returned when the requested change is only partly possible. Those differences are not edge cases. They are the daily work of a servicing team.

The first carrier is a platform, the second is a connection

Here is the split that makes the whole cost picture legible.

Integrating the first airline does not buy one airline. It buys a normalisation layer: a canonical internal representation of an offer, an order, a passenger, a fare rule and an ancillary, plus the machinery around it. Retry and idempotency handling, because an order creation that times out has an unknown outcome and must be reconcilable. A conformance suite covering schema variance, because carriers extend the specification. Sandbox and certification workflow, because every carrier makes you prove yourself before production. Logging detailed enough to argue with an airline about what was returned.

None of that is rebuilt for the second carrier. What the second carrier costs is the delta between its behaviour and the canonical model you built for the first, and that delta is genuinely variable.

A carrier close to the reference implementation, offering a familiar ancillary set and conventional servicing, can be a couple of weeks. A carrier with an unusual seat map structure, its own interpretation of infant pricing, a distinct error taxonomy and a different guarantee window on offer expiry can cost most of a first integration again.

Maintenance is the other line that belongs in the first plan rather than the second year. Carriers version their APIs, deprecate fields and change behaviour, and each connection carries a share of that. A reasonable allowance is 10 to 15 per cent of the original integration hours per carrier per year, which on a portfolio of six carriers is a standing commitment rather than an occasional task.

The practical planning consequence: sequence carriers deliberately. Build the platform against a carrier with clean, well-documented behaviour, then add the awkward one second rather than tenth, because the awkward one is what tells you whether the canonical model is real or merely the first carrier wearing a different name.

One further element of the platform deserves naming because it is invisible in a demonstration and mandatory in production. Every carrier requires you to pass through their sandbox and certification process before you touch live inventory, on their timetable and with their test cases. That is calendar time you do not control, it frequently uncovers behaviour the documentation did not mention, and it has to be repeated to some degree for each carrier. Plan it as a dependency with a lead time rather than as a task at the end of the build.

Servicing is where the estimate breaks

Almost every underestimate in this domain has the same cause. Shopping was scoped and servicing was assumed.

Shopping and booking are the pleasant half. A search, an offer, a price, an order, a payment. It demonstrates well and it is what a proof of concept covers. Servicing is everything afterwards, and it is where a travel business actually lives: a schedule change pushed by the airline, a voluntary change requested by the passenger, a partial cancellation, a refund with a fare rule attached, a name correction, a void inside the permitted window, a disruption that rebooks passengers onto another carrier entirely.

Each of those has to work against every connected carrier, and each carrier expresses them differently. Worse, several of them are asynchronous. The airline notifies you that something changed, which means your system needs somewhere to receive it, a way to reconcile it against the Order you believe you hold, and a decision path for a human when the two disagree.

There is also the awkward operational reality that servicing frequently has to happen at a time when the carrier's interface is unavailable, and that agents will fall back to a phone call. A design that has no path for a manual action recorded against a machine-held Order will produce records that drift out of agreement with the airline, and that drift surfaces at settlement.

Scope servicing as its own module with its own number. An NDC integration that can sell but cannot service is not a partial delivery. It is an operational liability, because it can create obligations it cannot then modify.

There is one more asymmetry worth pricing deliberately. Ancillaries are where carriers differentiate hardest, because that is where their margin sits, and differentiation is exactly what a canonical model struggles with. Bags, seats, lounge access, priority boarding, meals and bundles are all expressed as products, and carriers disagree about whether a bundle is one product or several, whether a seat is priced per passenger or per segment, and what happens when an ancillary survives a change to the flight it was attached to. Budget more time for ancillaries than the feature list suggests, and expect the seat map to be the single most carrier-specific piece of the entire integration.

You will run two worlds at once for years

Any plan that reads as a cutover from legacy distribution to NDC should be rewritten.

The global distribution systems still carry a great deal of traffic, and a large part of the world's content remains reachable that way. Carriers are adopting the newer model at their own pace, with industry aspiration pointing at capability around 2030 and many carriers realistically landing in the 2028 to 2029 window. A system that can speak only one of the two will be wrong in one direction or the other for several years.

Dual running has a specific and frequently unbudgeted cost, and it is not the second connection. It is reconciliation. The same trip may exist as an Order with one carrier and as a record with a ticket and miscellaneous documents through another, and finance needs one view of both. Building a booking abstraction that spans both worlds without lying about either is harder than either integration, and it is the piece most likely to be discovered late.

Treat that abstraction as a first-class module. Design it when the first NDC carrier goes in, not when the finance team asks why the two reports disagree.

There is a second dual-running cost that is easy to miss during scoping, and it is human rather than technical. Agents have to be trained on two servicing paths, and for a period they will not know which one applies to the booking in front of them until they look. Any interface that does not tell an agent immediately which world a trip lives in will generate errors that look like software defects and are not. Showing the provenance of a booking on the record itself is a small piece of work that removes a large class of support load.

Aggregator or direct is arithmetic, not ideology

This decision is usually argued on principle and should be settled with a spreadsheet.

An aggregator gives one integration and many carriers behind it. It absorbs the per-carrier variance that this article has been describing, it maintains connections as carriers change, and it charges for that, usually per transaction or per booking. Direct connections cost engineering time per carrier and ongoing maintenance, and they give control over the offer, better margin at volume, and no dependency on somebody else's roadmap.

The arithmetic is a crossover. Take a per-booking aggregator fee and multiply it by expected annual volume, then compare it against the first-carrier build plus the deltas for the carriers you actually need plus an honest maintenance allowance. At low volumes the aggregator wins comfortably and it is not close. At high volumes on a small number of core carriers, direct wins, and the usual answer for a growing business is a hybrid: direct connections to the handful of carriers that carry the majority of bookings, aggregator coverage for the long tail.

A worked example makes the shape clear. Take an aggregator fee of $2 per booking and an agency doing 40,000 bookings a year. That is $80,000 annually, recurring. A first direct carrier at 1,290 hours is $83,850 at the blend, so on paper the build pays back inside about thirteen months. The comparison only holds if that one carrier actually carries the bookings, though. If the 40,000 are spread across fifteen airlines, going direct means the first carrier plus fourteen deltas, which at 120 to 320 hours each adds somewhere between $109,200 and $291,200 before maintenance, and the aggregator wins comfortably.

That is the real decision. Concentration of volume, rather than volume itself, is what makes direct connections pay.

The mistake worth avoiding is going direct with everything for the sake of independence, then maintaining a dozen connections that each produce a fraction of a per cent of revenue.

What NDC API integration costs, with the hours shown

Here is the rate, the hours and the multiplication.

The rate band for travel work is $40 to $100 per hour by role. Reporting and administration sit near the floor. Availability modelling and refund logic sit near the ceiling. A mixed team blends to about $65.

The scope below is the carrier connection layer for a first airline. It excludes the booking platform itself, and it excludes any accreditation fee, which belongs to a body rather than to an engineering budget.

Module	Hours
Discovery and carrier capability audit	60
Canonical offer and order model	260
Shopping, pricing and order creation	240
Servicing: change, cancel, refund, void	240
Ancillaries and seat maps	150
Reconciliation against the legacy record	200
Error taxonomy, retries and idempotency	140
First carrier total	1,290

One thousand two hundred and ninety hours runs $51,600 at $40, $129,000 at $100, and $83,850 at the $65 blend.

Each additional carrier is the delta rather than the whole. In practice that is 120 to 320 hours, which is $7,800 to $20,800 at the blend. That range is the honest version of the per-airline figures published elsewhere, and the position within it is set by how far the carrier sits from your canonical model rather than by its size.

A sequence that reaches a sellable slice

Build the canonical model first, from the published specification rather than from one carrier's implementation, then let the first carrier correct it. A model derived from a single airline is that airline's model with different names on the fields.

Take shopping and order creation next, and put idempotency in from the start. An order creation with an unknown outcome is the single most expensive defect in this domain, because resolving it means a human talking to an airline about whether a passenger is booked.

Add reconciliation against the legacy record third, before the second carrier. It is the module most likely to change the shape of everything else, and discovering that after three integrations means reworking three.

Then servicing, which will take longer than scoped and should be given room, followed by the deliberately awkward second carrier as the real test of the abstraction.

A slice of this shape reaches a sellable and serviceable state with one carrier in roughly 16 to 22 weeks with a small team, of which two to four weeks is usually the carrier's certification process rather than your engineering.

Two questions are worth asking a carrier before quoting their integration. How is a voluntary change handled, as a modification to the existing Order or as a cancel and rebook, and is the price held during the exchange. And what is returned when a requested change can only be partly fulfilled. The answers separate a two-week carrier from a two-month one, and they are rarely in the marketing material.