British Airways NDC API Integration

If you're building or scaling a booking platform for an OTA, TMC, or DMC, you've probably run into the same wall every developer hits eventually: GDS content alone doesn't cut it anymore. Airlines want to sell their own fares, their own ancillaries, and their own personalized offers — and British Airways is one of the more mature carriers doing exactly that through its NDC API.

This guide walks through what British Airways' NDC implementation actually looks like from an integration standpoint: the authentication model, the Offer and Order Management workflow, ancillary and seat map retrieval, and the architectural patterns that keep this kind of integration stable in production.

Why British Airways NDC Matters for Travel Platforms

British Airways moved onto NDC to distribute richer content directly to travel sellers, bypassing some of the constraints of legacy EDIFACT messaging over traditional GDS pipes. For platform builders, that translates into a few concrete advantages:

• Access to BA-exclusive fares and bundles not always available via GDS

• Full ancillary catalogs — seat upgrades, extra baggage, and onboard products — surfaced at shopping time rather than bolted on after booking

• Dynamic, personalized pricing tied to traveler profile and booking context

• Reduced dependency on GDS surcharges for certain content types

The tradeoff is integration complexity. NDC is a stateful, order-centric model (Shop → Offer → Order → Servicing), which is a meaningfully different mental model than the request/response pattern most developers are used to from traditional flight APIs.

Core Building Blocks of the Integration

1. Authentication (OAuth2)

British Airways' NDC endpoints sit behind OAuth2 client-credentials authentication. Your platform requests an access token using a client ID and secret, then attaches that bearer token to every subsequent NDC call. Tokens are short-lived, so a production integration needs:

• A token refresh scheduler that renews before expiry, not after failure

• Secure credential storage (never hard-coded, ideally in a secrets manager)

• Retry logic that distinguishes an expired-token 401 from a genuine authorization failure

2. AirShopping — Offer Discovery

The AirShopping request is where a search query (origin, destination, dates, passenger count) gets converted into a list of priced offers. Each offer returned by BA's NDC API includes an OfferID and associated OfferItemIDs — these are session-bound references, not static fare codes, and they typically expire within a defined TTL window.

This is the detail that trips up teams migrating from GDS-style integrations: you can't cache an offer indefinitely and re-price it later. The offer is a live quote tied to inventory and fare rules at the moment of shopping.

3. Offer Price — Re-validation Before Booking

Before committing to OrderCreate, best practice (and often a required step) is to call OfferPrice to re-validate the offer — confirming the fare, taxes, and ancillary pricing are still accurate. This protects against stale-offer bookings and mismatched pricing at checkout.

4. OrderCreate — Booking Execution

OrderCreate converts a validated offer into a live PNR-equivalent order. This is where passenger details, payment information, and any selected ancillaries get bundled into the final booking request. A successful response returns an OrderID, which becomes the reference for all future servicing calls.

5. Order Servicing — Post-Booking Changes

NDC's Order Management model treats the booking as a living order rather than a static record. Servicing calls (OrderChange, OrderRetrieve, OrderCancel) let your platform handle seat changes, ancillary add-ons, and cancellations against the same order lifecycle — which is a cleaner model than juggling separate PNR modification workflows, but it does require your data layer to track order state transitions carefully.

Handling Ancillaries and Seat Maps

One of the main reasons platforms pursue NDC integration in the first place is ancillary access. British Airways exposes ancillaries as OfferItems alongside the base fare — seat selection, extra baggage, and onboard products all arrive in the same shopping response rather than as a bolt-on upsell screen.

Practical implementation notes:

• Seat maps are typically retrieved via a SeatAvailability request tied to the specific offer, not a generic flight-level seat map — meaning seat inventory reflects the fare class and booking context of that traveler.

• Ancillary pricing can change between shopping and booking, which is another reason OfferPrice re-validation isn't optional in a well-built integration.

• Bundling ancillaries into the initial OrderCreate call (rather than servicing them in afterward) generally produces a smoother checkout UX and fewer round trips.

Architecture Patterns for a Stable Integration

Because NDC is order-stateful and session-bound, a naive request/response wrapper around the API tends to break down under real traffic. A few patterns that hold up well in production:

Adapter pattern for multi-source normalization. If your platform also pulls GDS or other NDC-enabled airline content (Lufthansa, Air Canada, and others each have their own NDC quirks), an adapter layer that normalizes offers, ancillaries, and order objects into a common internal schema keeps your booking engine airline-agnostic.

Redis caching for token and offer-session state. Access tokens and short-lived offer references are natural candidates for a fast in-memory cache, reducing redundant AirShopping calls and avoiding unnecessary auth round trips.

Circuit breakers around the NDC endpoint. NDC APIs, including BA's, can have variable latency during peak shopping windows. A circuit breaker that fails fast and falls back to cached or alternate content (rather than letting a slow BA response cascade into a full search timeout) protects the overall booking experience.

Common Integration Pitfalls

• Treating OfferIDs as permanent fare codes. They're session- and inventory-bound; storing them long-term without re-validation leads to booking failures.

• Skipping OfferPrice before OrderCreate. This is the single most common cause of price-mismatch errors reported by teams new to NDC.

• Underestimating order-state complexity. Unlike a simple PNR record, an NDC order can have multiple valid states across shopping, booking, and servicing — your internal data model needs to mirror that lifecycle, not flatten it.

• Ignoring token expiry edge cases. A shopping session that spans a token refresh boundary needs to handle re-authentication transparently, without forcing the traveler to restart their search.

Final Thoughts

British Airways' NDC API gives OTAs, TMCs, and DMCs a path to richer content and better ancillary monetization than legacy GDS distribution alone typically allows — but it demands a genuinely different integration architecture, not just a new endpoint to call. Getting the offer lifecycle, caching strategy, and order-state model right up front saves significant rework later, especially once you're integrating multiple NDC-enabled carriers alongside BA.

If you're evaluating NDC integration for your booking platform — whether it's British Airways specifically or a broader multi-airline NDC strategy — Teenva AI & Digital Ventures builds and maintains these integrations for OTAs, TMCs, and DMCs. Reach out at sales@teenvaai.com or +91 9572020107 to talk through your architecture.