Travelport APIs: Air Distribution Platform Profile

Travelport JSON APIs expose air shopping, pricing, booking, ticketing and reservation-management capabilities across GDS and NDC content. For metasearch teams, the platform demonstrates how modern flight distribution needs to preserve offer identity and source-specific lifecycle rules beyond the initial search response.

Profile scope and access

This profile describes the JSON Air API surface rather than every product sold by Travelport. Its platform type is API and its audience is B2B; GDS and NDC describe content sources carried through that surface. The official getting-started guide requires provisioned customer credentials, so public documentation does not imply unrestricted production access. Regional entitlements and commercial fees cannot be derived from the general API description and remain unverified.

OAuth protects the API boundary

Travelport documents OAuth-based authentication and access-token reuse. Tokens should be managed centrally by the backend and refreshed according to their lifetime rather than requested for every individual search.

Authentication health belongs in operational monitoring because an expired or mismanaged token can look like upstream search failure.

Search and price are separate operations

The Flights APIs include search endpoints plus separate pricing and offer-building operations. This mirrors an important flight principle: the result shown during shopping may need validation before booking or exchange.

A metasearch aggregator should keep original offer references needed for later repricing.

GDS and NDC can coexist

Travelport supports both GDS and NDC content in parts of the workflow. The two sources can expose different rules, ancillaries and post-booking capabilities.

A normalized UI should not erase source differences that become important later in fulfillment.

Booking uses a workbench pattern

Travelport booking flows use a session/workbench concept where offers, travelers, payment and ancillaries are assembled before reservation commit.

This is a useful contrast with redirect-based metasearch: once a product takes ownership of booking, state management becomes significantly more complex.

Reservation lifecycle continues after purchase

The APIs cover reservation retrieval, cancellation, ticket documents, exchanges and other post-booking actions. Search architecture should therefore keep identifiers that can survive beyond the first offer.

Meta Search interpretation

Travelport illustrates why flight “offer” is not just itinerary plus price. Source, fare rules, branded fare, ancillary context and lifecycle capability all matter. Metasearch normalization should simplify comparison while preserving enough upstream identity for accurate provider handoff or deeper booking flows.