Flight API for Travel Portals: Integration Guide

A flight API is the technical interface that connects a travel portal to flight inventory: search, fare validation, booking, ticketing, and post-booking servicing. The right flight API choice shapes a portal's supplier coverage, pricing economics, and engineering investment for years. This page is the practical integration guide for developers, CTOs, and technical leads choosing between GDS, NDC, LCC, and aggregator routes.

We cover what a flight API actually does, the supplier landscape, the four-stage search-price-book-ticket lifecycle, the decision framework for choosing the right supplier mix, performance budgets, integration timelines, and how the adivaha platform bundles GDS, NDC, and LCC content behind a single connector.

For the broader API architecture context, see our hub on travel API integration. For deeper coverage of specific supplier types: GDS API integration, NDC API integration, and LCC API integration. For the commercial portal that bundles flight, hotel, and other APIs, see our hub on white label travel portal.

What a Flight API Actually Does

A flight API exposes the operations a travel portal needs to sell flight inventory end-to-end. The interface varies by supplier (GDS, NDC, LCC, consolidator) but the conceptual operations are consistent.

Core operations

• Search - origin, destination, dates, passenger count, cabin class, optional filters. Returns priced offers with short TTL (typically 5-30 minutes).
• Price-and-rules - re-verify the chosen offer is still bookable, surface fare rules (refundability, change fees, baggage allowance).
• Book - create a persistent record (PNR for GDS, Order for NDC, carrier-specific for LCC) with passenger details. Holds inventory but not yet ticketed.
• Ticket / Confirm - issue the ticket, charge payment, deliver itinerary and e-ticket to the traveler.
• Service - post-booking operations: changes, refunds, voids, ancillary additions, special service requests (SSRs), seat selection, name corrections.

Why the operations differ across suppliers

GDS uses an edited-fare model: airlines file fares, GDS edits them, sellers see a normalized view. NDC inverts this: airlines create the complete offer (including ancillaries) and sellers consume it as-is. LCC carriers use direct APIs that are carrier-specific and often expose richer ancillary content than GDS. A flight API integration must handle all three patterns transparently so the portal can offer a unified booking flow regardless of supplier.

The Flight API Supplier Landscape

Three categories of suppliers provide flight content. Most production portals integrate all three for broad coverage.

GDS (Global Distribution Systems)

The traditional backbone of flight distribution. Three major GDS operators dominate: Amadeus (strongest globally), Sabre (strongest in North America), Galileo / Travelport (strong in Europe and Middle East). GDS gives the broadest carrier coverage in a single integration but lacks rich ancillary content. Per-booking distribution cost is significant (USD 5-12 per ticket), which is why airlines are shifting volume to NDC.

NDC (New Distribution Capability)

IATA-led XML standard launched in 2012. Lets airlines distribute richer content directly: branded fares, ancillaries (seats, baggage, meals, lounge access), and personalized offers. NDC content is increasingly the only path to certain airline inventory - major carriers (Lufthansa Group, Singapore, British Airways, Qantas, Emirates) distribute meaningful inventory only through NDC. Two ways to access: aggregator NDC (through Amadeus or Sabre) or direct airline NDC APIs.

LCC (Low-Cost Carrier) APIs

Most low-cost carriers (IndiGo, AirAsia, Ryanair, Wizz, easyJet, Jetstar, Cebu Pacific, VietJet) distribute outside GDS through their own APIs or specialized aggregators (Travelfusion, Mystifly, TBO, Avia Solutions). LCC content is essential for routes where low-cost carriers dominate market share - that includes most domestic Indian routes, intra-Europe, and intra-SE Asia.

The Search-Price-Book-Ticket Lifecycle

Every flight API integration handles the same four operational stages. Understanding the lifecycle shapes architecture decisions.

Stage 1: Search

The traveler enters origin, destination, dates, passenger count. The platform fans out search calls in parallel to all configured suppliers (typically 5-15) with a hard deadline budget (sub-800ms p95). Each supplier returns a list of priced offers with short TTLs. The platform merges, deduplicates, and ranks results. Most travelers compare multiple offers before selecting one. Cache aggressively at this layer with 30-180 second TTLs.

Stage 2: Price-and-rules

Once the traveler picks an offer, the platform re-verifies it is still bookable (offers can expire between search and book) and surfaces fare rules: refundability tier, change fees, baggage allowance, mileage accrual eligibility, carrier-specific terms. This stage runs against a single supplier for the chosen offer; typical latency 200-400ms. Some platforms collapse search and price-and-rules into a single shopping call; others split for performance.

Stage 3: Book

The platform creates the persistent record. For GDS this is a PNR (Passenger Name Record); for NDC it is an Order; for LCC it is carrier-specific. The booking holds inventory but does not yet ticket - the traveler can confirm payment in this state. Most platforms hold for 15-30 minutes before requiring payment.

Stage 4: Ticket and Service

Payment is charged, the ticket is issued against the PNR/Order, the e-ticket and itinerary are delivered to the traveler. Post-ticketing servicing happens through the same API surface: change requests, refunds, voids (within 24 hours), ancillary additions, name corrections, special service requests. Different supplier types service differently - GDS uses PNR servicing flows, NDC uses Order servicing APIs, LCC uses carrier-specific endpoints.

Choosing the Right Flight API Mix

The decision framework for portal teams comes down to three signals.

Signal 1: Route mix

Pick suppliers by where your travelers go. Domestic India: IndiGo, SpiceJet (LCC) dominate. Intra-Europe: Ryanair, easyJet, Wizz. North America: legacy carriers plus Spirit/Frontier/JetBlue (mixed GDS/LCC). SE Asia: AirAsia, Cebu Pacific, VietJet. Long-haul international: GDS plus NDC for major carriers. The route mix dictates whether GDS is enough or whether LCC and NDC integration are essential.

Signal 2: Engineering capacity

Direct integrations are 4-14 weeks per supplier plus ongoing maintenance. Aggregators are 2-6 weeks for many suppliers but at slightly higher per-transaction cost. Platforms like adivaha collapse this to 1-3 weeks because the connectors are pre-built. Pick based on whether your team has the bandwidth to maintain per-supplier connectors over years.

Signal 3: Ancillary economics

If your portal expects to derive significant revenue from ancillaries (seat selection, baggage, meals), NDC and LCC content are essential. GDS-only content limits ancillary revenue to a small fraction of what NDC and LCC enable. For most modern portals, ancillaries are 20-40 percent of flight revenue - skipping them is a major economic loss.

Performance Budgets and Architecture

Flight booking has unforgiving latency expectations because travelers comparison-shop across multiple portals.

Caching strategy

Cache search results aggressively (30-180 second TTLs) keyed on the search parameter fingerprint. Never cache price-and-rules, book, or ticket responses - those operations always go to the supplier. Use Redis or a similar in-memory store with explicit TTLs.

Queue infrastructure

Use queues for non-user-blocking work: webhook delivery, voucher generation, post-booking confirmation emails, supplier reconciliation. Keep the synchronous booking path as thin as possible.

The adivaha Flight API Implementation Pattern

The platform bundles GDS, NDC, and LCC content behind a single connector. Three reasons portals choose this pattern:

One integration covers many suppliers. One adivaha integration connects to Amadeus (GDS + NDC), Sabre (GDS + NDC), Galileo, plus the top 50 LCC carriers through pre-built aggregator connections (Travelfusion, Mystifly, TBO, Avia Solutions). Your engineering team writes one connector; we maintain the upstream relationships.

Mature operational layer. Refund workflows, exchange handling, void processing, ancillary management, and supplier reconciliation are production-tested across hundreds of portal deployments. Your team skips the operational learning curve.

Unified booking flow. Travelers experience a single booking flow regardless of whether the underlying supplier is GDS, NDC, or LCC. The platform handles the channel-specific differences (PNR vs Order vs carrier-specific) transparently.

Pricing and Plans

adivaha Flight API access is included in our two standard plans plus a custom tier.

Standard: USD 999 setup + USD 99/month

Full Flight API coverage through GDS (Amadeus, Sabre, Galileo), NDC (aggregator and select airline-direct), and LCC content. Sandbox access, REST/JSON documentation, ancillary support, refund workflows. See full pricing.

Custom (enterprise scope)

Same Flight API coverage as Monthly, billed annually. Includes the B2B sub-agent module for portals running agent networks. Saves USD 789 a year.

Custom

For portals needing direct airline NDC integrations beyond our standard roster, custom IATA accreditation support, enterprise SLA terms, or carrier-specific certification programs. Talk to sales.

Sandbox and Documentation

All plans include sandbox access for Flight API integration testing without committing to production. The sandbox covers GDS test airlines, NDC test offers from major carriers, and LCC test bookings. Available within 24 hours of account creation. API documentation lives at docs.adivaha.com with REST/JSON examples, Postman collection, OpenAPI specification, and per-carrier integration notes.

Why adivaha for Flight API Integration

Three reasons portals choose adivaha as their Flight API partner.

Multi-channel coverage in one integration. GDS, NDC, and LCC content all accessible through a single REST/JSON connector. Your engineering team writes one integration instead of dozens.

Production-grade operations. Refund, exchange, void, ancillary, and reconciliation flows are all production-tested across hundreds of portal deployments. Mature operations from day one.

Architecture built for scale. Performance budgets, parallel fan-out, deadline budgets, async queue infrastructure - all baked into the platform. Your portal handles flight booking volume from day one without re-engineering.

FAQs

Q1. What is a Flight API and what does it enable?

A Flight API is the technical interface for searching, pricing, booking, ticketing, and servicing flight inventory. It connects portals to GDS, NDC, LCC, and consolidator sources through REST/JSON or SOAP/XML endpoints.

Q2. What is the difference between GDS, NDC, and LCC content?

GDS aggregates filed fares centrally. NDC has airlines create offers directly with richer ancillaries. LCC content comes from carriers that distribute outside GDS through direct APIs or specialized aggregators.

Q3. How do I choose between GDS, NDC, and direct LCC APIs?

Pick by route mix and operational priorities. GDS for breadth, NDC for rich content on participating airlines, LCC for low-cost carrier-dominant routes. Most portals run a hybrid; adivaha bundles all three.

Q4. What does a flight API integration cost?

adivaha is USD 99/month (with USD 999 one-time setup) or (included in Standard above) plus per-transaction fees. Building in-house through one aggregator costs USD 30K-120K upfront plus maintenance. Direct GDS is USD 50K-200K per GDS.

Q5. What is the search-price-book-ticket lifecycle?

Four stages: Search (query suppliers in parallel), Price-and-rules (verify offer is still bookable with fare rules), Book (create PNR/Order), Ticket (issue against PNR/Order, charge payment). Post-ticketing servicing follows.

Q6. What is the typical latency budget?

Search across 5-15 suppliers: under 800ms p95. Price-and-rules: 200-400ms. Book: 400-800ms. Ticket: 400-1500ms. Full checkout with payment: under 3 seconds.

Q7. How long does flight API integration take?

Aggregator: 2-6 weeks. Direct GDS: 4-12 weeks per GDS. Direct NDC: 6-14 weeks per carrier. On adivaha: 1-3 weeks because connectors are pre-built and centrally maintained.

Q8. Can I mix GDS and NDC in the same search results?

Yes. Results merge with clear labeling. Behind the scenes, PNRs (GDS) and Orders (NDC) are serviced through different APIs; the platform routes correctly.

Q9. What payment patterns work for flight bookings?

Card via your gateway with IATA-issued tickets (requires IATA accreditation), card via consolidator that issues on its IATA, or pay-direct-to-airline for LCC carriers.

Q10. What ancillaries can I sell through the Flight API?

Through NDC/LCC content: seats, baggage, meals, lounge access, fast-track security, priority boarding, WiFi, branded fares, carbon offset, insurance. GDS offers fewer ancillaries.