Flight Reservation API Patterns for OTAs and Aggregators

Flight reservation API is the programmatic interface that lets a travel platform create, hold, and manage flight bookings on the airline's reservation system. The API handles the booking lifecycle - creating the Passenger Name Record (PNR), holding seats, capturing passenger details, applying special services, and tracking the reservation through ticketing and beyond. It is the airline-side counterpart to the OTA-facing search and book interface, the layer where the booking becomes a real reservation in the airline's system rather than just a search result. This page covers what flight reservation APIs actually do, the lifecycle of a PNR through the reservation system, the GDS, NDC, and aggregator API options, the integration patterns that distinguish production-grade reservation handling from prototype-grade implementations, and the reconciliation work that keeps the platform's records aligned with airline truth. The companion guides for the broader flight-booking and reservation context are flight reservation system as the cluster anchor, airline reservation system for the airline-side framing, flight ticket booking API for the broader booking-API view, and airline ticketing system for the ticket issuance flow. Cross-cluster reach into airline API integration covers the broader airline-API patterns.

The PNR Lifecycle Through A Flight Reservation API

The Passenger Name Record (PNR) is the central artefact in flight reservation. Every booking exists as a PNR in the airline's reservation system, identified by a 6-character alphanumeric locator that travellers see on their itinerary. The flight reservation API creates and manages PNRs through a lifecycle of states the platform must handle correctly. PNR creation happens after the user selects an itinerary and provides passenger details. The reservation API call sends the itinerary, passenger names, contact details, and payment intent; the airline returns a PNR with held seats and a confirmed locator. The PNR is in held state at this point - seats are reserved but no ticket has issued yet. Hold expiry applies to most reservations. The airline gives the platform a defined window (typically 15 minutes for retail booking, longer for B2B and corporate) to complete payment and issue the ticket. Past the hold window, the PNR can be cancelled by the airline if no ticketing happens. The platform's flow has to complete payment within the hold window or lose the reservation. Adding special services through additional API calls covers seat selection, meal preferences, baggage allowance, frequent flyer numbers, special-needs accommodations (wheelchair, unaccompanied minor), and other ancillary attachments. Each service modifies the PNR; some are free, others carry fees that affect the total. Ticketing converts the held PNR into an issued ticket. The ticketing API call confirms payment is captured, creates the e-ticket number against the PNR, and transitions the PNR from held to ticketed state. The 13-digit e-ticket number is the artefact the traveller carries through the rest of the journey. Modifications after ticketing apply airline-specific rules. Date changes, route changes, name changes (where allowed), and re-issues each have their own API patterns and fee structures. The platform's servicing flow calls these APIs and applies fees according to the airline's published policy. Cancellations apply the airline's cancellation policy, calculate refund eligibility, process the refund through the original payment provider, and update the PNR to cancelled state. Refund timelines vary by airline and payment method; the platform should set the right expectation rather than promising specific dates. Schedule changes initiated by the airline arrive through webhooks or PNR queue notifications. The platform consumes these, updates the booking, notifies the traveller, and offers re-routing if the change breaks the itinerary. PNR retrieval through the reservation API lets the platform fetch the current state of any booking - useful for status queries, reconciliation, and customer support. The retrieve operation returns the full PNR including all modifications, ticketing status, and any queue notes. The cluster guide on airline ticketing system covers ticketing-side specifics, and the broader system map is in airline system management.

The cluster guides below cover the reservation lifecycle, broader booking-API context, and integration patterns that interact with flight reservation API integration in production.

GDS, NDC, And Aggregator Reservation API Options

Three categories of reservation API serve OTAs and B2B platforms with different shape and depth. GDS reservation APIs from Amadeus, Sabre, and Travelport handle reservation operations through legacy SOAP/XML protocols. The APIs are deep, well-documented through aggregator wrappers, and supported by per-supplier certification. The reservation lifecycle (PNR create, fare quote, ticket, modify, cancel, refund) has many states and transitions that each operation must respect. GDS APIs cover thousands of airlines through the aggregated GDS network. NDC reservation APIs from participating airlines handle the offer-and-order model that NDC defines. The airline constructs an offer; the partner submits an order to accept; the offer-and-order flow replaces the GDS PNR-and-fare-quote pattern. NDC reservation APIs deliver richer ancillary catalogues, dynamic pricing, and personalised offers that GDS cannot easily express. The trade-off is per-airline integration work; each airline implements NDC with its own quirks. Aggregator reservation APIs wrap GDS and direct airline access into a single REST interface. Aggregators handle the complexity of GDS protocols, NDC variations, and direct-API quirks, exposing a normalised API to the OTA. The trade-off is extra fees, reduced control over channel routing, and dependency on the aggregator's roadmap. Selecting between options depends on the OTA's scale, audience, and engineering capacity. Smaller OTAs benefit from aggregator APIs that simplify integration. Mid-market OTAs typically integrate one GDS directly plus selected NDC airlines for the spread economics. Large OTAs run all three channels to maximise inventory coverage and channel-mix optimisation. Authentication and session management patterns differ across the three. GDS APIs typically use Pseudo City Code (PCC) and session tokens that need refresh during long-running flows. NDC APIs use OAuth or API keys with shorter-lived tokens. Aggregator APIs typically use API keys with simpler authentication. The platform's adapter layer handles each pattern correctly. Idempotency on reservation operations is critical because retrying a failed PNR creation could create duplicate reservations. The platform must use idempotency keys per request, especially on payment-triggering operations like ticketing. Rate limiting per supplier API affects the platform's throughput. GDS APIs typically allow generous rate limits for established partners. NDC airlines often have stricter per-airline limits. Aggregators apply their own rate limits on top of supplier limits. The adapter layer should respect rate limits to avoid 429 responses that fail user-facing requests. Error handling needs supplier-specific knowledge. A GDS error code that means "fare invalid" requires different handling than an NDC airline error meaning "offer expired" or an aggregator error meaning "supplier unreachable". The adapter layer maps supplier errors to platform-internal error categories with consistent semantics. The cluster guide on airline API integration covers the integration patterns, and the cross-cluster supplier-economics view is in OTA commission on airline tickets.

Production Patterns That Hold Up Under Load

Production-grade flight reservation API integration follows patterns that distinguish it from launch-day implementations. Five patterns matter most. Adapter isolation per supplier hides reservation-API-specific complexity behind a clean internal interface. The platform's booking flow calls the adapter; the adapter handles authentication, protocol translation, error mapping, and supplier-specific quirks. Adapter isolation lets the platform swap or add suppliers without rewriting the booking flow. Idempotency keys on every reservation operation prevent duplicate PNRs and duplicate tickets on retry. The platform generates a unique key per logical operation; the supplier respects the key by returning the original response on repeat calls within the dedup window. Without idempotency, a network blip during ticketing could create two tickets for the same booking, costing the platform real money. Circuit breakers per supplier track recent error rate and latency. When a supplier degrades, the breaker opens and stops calling the failing supplier for a cool-down period. Bookings route to alternate suppliers where possible; the user sees clear messaging where not. Without circuit breakers, a slow supplier turns every reservation attempt into a long-running failure. Retry with exponential backoff handles transient failures. Network blips, rate limit responses, and supplier hiccups recover on retry. The retry budget is bounded - typically 1 to 3 retries with backoff doubling each time - so retries do not extend latency past the user-facing budget. Combined with idempotency, retries do not create duplicates. Audit logging per reservation operation captures the request, response, and outcome with full context. The audit log supports debugging when reservations go wrong, defending in commercial disputes (with airlines, payment providers, regulators), and reconciling against supplier settlement. The log retention period typically follows the airline's contractual requirement (7 years for IATA-related data). Webhook handling consumes supplier-initiated events on reservations - schedule changes, fare drops, cancellations from the supplier side, ticketing confirmations. The platform's webhook receiver must be idempotent (the same event delivered twice should not create two updates), should ack early (return 200 quickly to avoid supplier retries), should process asynchronously through a queue (long processing should not block the supplier's webhook delivery), and should support replay (missed events should be replayable from the supplier's history endpoint). Reservation queue handling in GDS context manages PNRs that need attention - schedule-change PNRs, ticketing-failure PNRs, special-handling PNRs. The platform should pull from the supplier's reservation queue regularly and surface queued items to operations for handling. Observability per reservation operation covers latency, error rate, success rate by call type, and webhook ingestion lag. Alerts fire on rate-of-change as well as absolute thresholds. Dashboards distinguish platform-side issues (high error rate on a controller) from supplier-side issues (high error rate on Amadeus reservation calls). The cluster guide on real-time travel API integration covers the runtime patterns, and the broader OTA architecture is in airline booking system architecture.

Reconciliation, Servicing, And Operational Reality

Reservation operations that go right rarely consume the operations team's attention. The ones that go wrong consume most of it. The reservation API's role in handling failure modes well decides whether the platform stays trusted across millions of bookings. Daily reconciliation matches the platform's record of created reservations and issued tickets against the airline's settlement file or BSP report. Discrepancies surface in a queue with SLA - missing tickets (the platform created a PNR and thought ticketing succeeded, but the airline did not record the ticket), fare class mismatches (booking class differs from what was offered), refund processing delays, PNR status drift between platform and airline records. Each discrepancy type has a specific resolution path. Refund reconciliation tracks refund requests through the airline's queue. The platform's refund flow calls the reservation API to initiate refund, captures the airline's confirmation, processes the credit through the original payment provider, and updates the booking record. Refund timelines vary by airline and payment method; the platform should communicate progress rather than waiting silently. Servicing operations through the reservation API cover the long tail of changes - date changes, route changes, name changes, special service additions, voluntary upgrades. Each operation calls the appropriate reservation API endpoint, applies the airline's fee rules, and updates the booking record. The servicing UI for travellers and reservations agents should expose these operations cleanly without exposing the underlying API complexity. Group servicing for tour operators and B2B aggregators consolidates servicing requests across multi-traveller bookings. A group of 30 travellers on the same flight need shared handling for schedule changes; individual travellers within the group may need separate handling for personal changes. The platform's group-aware servicing supports both patterns. Schedule-change handling is the highest-impact servicing flow. Airlines change schedules continuously - new aircraft, route adjustments, time shifts, cancellations, equipment changes. The platform consumes schedule-change webhooks, updates affected PNRs, notifies travellers, and offers re-routing where available. Travellers who learn about schedule changes through the platform stay engaged; travellers who learn at the airport lose trust permanently. Disruption operations handle airline-side cancellations and major schedule changes that affect many travellers at once. A weather event cancelling 200 flights creates a wave of affected reservations the platform must handle within hours. The reservation API's batch operations and the platform's queue-based processing capacity decide whether disruption handling stays manageable or breaks down under load. The audit trail across all reservation operations is the platform's defence in commercial disputes. Every reservation create, modify, cancel, refund, schedule-change response, and traveller communication should log immutably with full context. The audit log is queryable by booking, by traveller, by route, by date, and by operation type. Compliance integration applies through the reservation flow - PCI for payment data captured during ticketing, GDPR or local equivalent for personal data in PNRs, IATA standards for ticketing operations, and country-specific privacy laws applying to PNR data sharing. The reservation adapter respects these rules at the API level. The honest framing is that flight reservation API integration is one of the harder specialised engineering domains in B2B software. The OTAs that staff or partner well end up with platforms that survive supplier changes, scale on traffic, and report finance numbers that match supplier settlement. The OTAs that under-invest discover the gaps during peak season - which is the worst possible time. The cluster anchor on flight reservation system covers the broader OTA-facing view, and the cross-cluster integration patterns are in travel API development services. Flight reservation APIs done well are not visible to travellers; they are simply the plumbing that makes flying possible. The platforms that get them right run reliably across millions of bookings; the platforms that get them wrong rebuild integration after integration without ever feeling stable.

FAQs

Q1. What is a flight reservation API?

A flight reservation API is the programmatic interface a travel platform uses to create, hold, and manage flight bookings on the airline's reservation system. The API handles the booking lifecycle - creating the Passenger Name Record (PNR), holding seats, capturing passenger details, and tracking the reservation through ticketing and beyond.

Q2. How is a flight reservation API different from a flight booking API?

A flight booking API typically encompasses the full search-to-book flow including fare quote, ticket issuance, and post-booking servicing. A flight reservation API focuses specifically on the reservation creation and management - holding seats, managing PNRs, applying special services, and the lifecycle of the reservation before and after ticketing.

Q3. What are PNRs and why do they matter?

A PNR (Passenger Name Record) is the airline's internal record for a booking. It contains passenger details, itinerary, fare, ticketing status, special services, and the booking's lifecycle history. The PNR is the central artefact in flight reservation - all reservation API calls create, modify, or query PNRs.

Q4. What operations does a flight reservation API support?

Create PNR with passenger details and itinerary, fare quote against the held PNR, add special services (meal preferences, baggage, seat selection), modify passenger details, update the itinerary (date or route changes), cancel the PNR, retrieve PNR history, and queue PNRs for review.

Q5. Which providers offer flight reservation APIs?

Major GDS providers (Amadeus, Sabre, Travelport) offer reservation APIs as part of their broader API suite. Direct airline NDC connections include reservation operations alongside offer-and-order flow. Aggregator wrappers (third-party API providers that wrap GDS plus direct airline access) simplify reservation API access for partners that want unified integration.

Q6. How does a flight reservation API integrate into an OTA's platform?

The OTA's adapter layer wraps the reservation API in a normalised internal interface that the rest of the platform consumes. The adapter handles authentication, request mapping, response parsing, error handling, and supplier-specific quirks. The booking flow calls the adapter to create the PNR; the cart calls it to add ancillaries; the servicing flow calls it to handle changes.

Q7. What is the relationship between reservation API and ticketing?

A reservation holds seats but does not issue a ticket; the traveller is committed conditionally on payment. Ticketing converts the reservation into an issued ticket through a separate API call. The e-ticket number from ticketing carries through the rest of the lifecycle. Some patterns split reservation and ticketing into separate steps; others combine them.

Q8. How does NDC change flight reservation APIs?

NDC introduces an offer-and-order model where the airline constructs an offer (with fare, ancillaries, conditions) and the partner accepts the offer to create an order. The NDC order is the modern equivalent of the GDS PNR but with richer data and different lifecycle states. NDC reservation APIs are more modern in shape but each airline implements the standard with its own quirks.

Q9. What error handling does a flight reservation API need?

Network failures (retry with idempotency keys to avoid duplicate bookings), supplier-side rate limits (back off and retry), authentication expiry (refresh tokens before expiry), invalid passenger data (validate at the platform layer before calling the API), seat-unavailable responses (fallback to alternate suppliers or surface to the user).

Q10. How does an OTA reconcile reservations with the airline?

Daily reconciliation matches the platform's record of created reservations and issued tickets against the airline's settlement file or BSP report. Discrepancies surface in a queue with SLA - missing tickets, fare class mismatches, refund processing delays, and PNR status drift between platform and airline records.