What is a flight API? How flight search and booking APIs actually work

A flight API is a web service that lets your software search for flights, price them and create bookings without a person typing into an airline website or a reservation terminal. Your application sends a structured request, for example one adult from London to Dubai on a given date in economy, and receives structured data back that it can display, filter and sell.

The first search is usually easy. The hard part is everything behind it: where the fares come from, why a price can change between search and payment, who issues the ticket, and what the provider expects from you in return. This guide covers all of it for founders, agency owners and developers who are new to airline distribution.

What a flight API does, in plain terms

Airlines do not publish one public database of seats and prices. Schedules, fares and availability live in airline reservation systems and in the distribution systems connected to them. A flight search API sits in front of one or more of those systems and translates them into something a web developer can work with, usually REST and JSON over HTTPS.

Most products cover two jobs. Shopping answers the question "what can I fly and what does it cost". Booking turns a chosen result into a reservation and then a ticket. Some providers sell only the first half, as search and price data for comparison sites. If you want to sell tickets, you need both halves.

Typical things people build on top of one:

• A booking website or white-label site for a travel agency
• An internal tool that lets agents quote and book faster than a terminal
• A corporate travel tool with company policies and approvals
• A mobile app, or a flights tab inside an existing product such as tour packages

Where flight data comes from: the three source families

Every provider ultimately gets its content from one of three kinds of source, and many mix them. Knowing which one you are talking to explains most of the differences in coverage, price and behaviour.

Global distribution systems (GDS)

GDSs such as Amadeus, Sabre and Travelport are the long-established networks that connect airlines with travel agencies. They aggregate schedules, fares and availability from many airlines and let agencies book and ticket in one place. Coverage of full-service carriers is broad, but access normally requires a commercial agreement and, for ticketing, either accreditation or a partner who holds it.

Airline NDC and direct APIs

NDC stands for New Distribution Capability. The International Air Transport Association (IATA) describes NDC as an XML-based data exchange standard built around offers and orders, which lets an airline create its own offers and distribute them through any channel. In practice that means fares, bundles and extras that may not appear in a traditional GDS feed.

Many low-cost carriers sit outside both worlds and expose their own direct APIs. The catch is the same in each case: every airline connection is a separate integration with its own commercial terms, test process and quirks.

Aggregators and consolidator APIs

An aggregator connects to many of these sources and exposes them through one API and one data model. A consolidator goes a step further: it also holds the ticketing relationships, so bookings are issued under its accreditation rather than yours. That is how a business can sell flights without its own IATA accreditation.

Each family has real trade-offs in content, cost and control. We compare them side by side in GDS vs NDC vs flight aggregator API.

The life of a flight API request, from search to ticket

Whatever the source, a booking moves through the same stages. The names change between providers, the sequence does not.

1. Search (shopping). You send origin, destination, dates, cabin and passenger counts by type: adults, children and infants. The provider queries its sources and returns a list of priced options.
2. Offer. Each option is an offer: a specific set of flights at a specific price, with an identifier and a limited lifetime. You keep the identifier, not just the price you displayed.
3. Price re-check. Before taking money you ask the provider to confirm that the offer is still available at that price. The answer can be yes, a new price, or no longer available.
4. Booking or order. You submit passenger names, dates of birth, contact details and any travel document data the route requires. The result is a reservation with a booking reference, often called a PNR or an order.
5. Ticketing. The reservation is paid and tickets are issued by an accredited entity, which settles with the airline through industry systems such as BSP, or ARC in the United States. Some APIs book and ticket in one call, others keep them separate with a time limit in between.
6. Post-booking. Retrieval, schedule change notices, cancellation, refunds, date changes and extras such as bags or seats. Support for these varies more than anything else on this list.

Public documentation shows the same pattern. The Duffel getting started guide, for example, walks through an offer request, selecting an offer and creating an order, and warns that offers go stale quickly and can no longer be booked once they do.

The re-check is the step newcomers skip. Treat "price changed" and "no longer available" as normal outcomes with their own screens, not as errors. A checkout that cannot handle them will fail in front of paying customers.

Why flight search is slow, and why results are cached

A single search can fan out to several suppliers, and each of them has to combine schedules, fare rules and live seat availability into valid priced itineraries. That is far more work than a typical database lookup, so responses take noticeably longer than most APIs a developer is used to.

Some providers make this explicit with an asynchronous design: you create a search, then poll for results or receive them in batches as each supplier answers. Others hold the connection open and return everything at once. Either way, your interface needs a proper loading state.

Searches also cost suppliers money, and the same routes and dates are requested again and again. So most providers cache: an identical search inside a short window is answered from stored results instead of a new supplier call. The trade-off is that a cached price can be slightly out of date, which is exactly why the re-check step exists.

We work the same way at IATA.co. Identical searches within a short window are answered from cache, and price and availability are always re-checked with the supplier before a booking is confirmed.

• Do not fire a search on every keystroke or date click. Search when the form is submitted.
• Treat the search price as indicative until the re-check confirms it.
• Cache static data such as airport and airline names on your side.
• Set generous timeouts for search and shorter ones for everything else.

What data comes back

Field names differ, but a useful search response contains the same building blocks:

• Itineraries: one per direction of travel. Some providers call them slices, legs or bounds.
• Segments: the individual flights inside an itinerary, with carrier, flight number, airports, terminals, times, aircraft and duration. A connection means two or more segments.
• Fare: base fare, taxes and fees, total and currency, usually broken down per passenger type.
• Cabin and fare brand: economy, premium economy, business or first, plus the booking class and the airline brand name where there is one.
• Baggage: cabin and checked allowance per passenger, by piece or by weight.
• Fare rules: whether the ticket can be changed or refunded, and the penalties that apply.
• Offer identifier and expiry: what you send back to price and book.

Map these into your own internal model early, especially if you may add a second supplier later. Pay particular attention to fare rules and baggage. They decide what your customer can do after purchase, and explaining them clearly is your responsibility as the seller.

Authentication, rate limits and look-to-book ratios

Most providers authenticate with an API key or an OAuth token sent in a request header. Keys belong on your server, never in browser code or a mobile app. Some providers, including us, also restrict each key to whitelisted server IP addresses, so a leaked key is useless from anywhere else.

Rate limits usually come in two forms: requests per minute and a monthly search quota. Go over and you should expect HTTP 429 Too Many Requests, which MDN documents as the status for a client that has sent too many requests in a given time, optionally with a Retry-After header. A well-behaved client reads the rate-limit headers and slows down before it hits the wall.

The look-to-book ratio is the number of searches you make for each booking you create. Suppliers pay for searches and earn on bookings, so many of them monitor this ratio and may charge for, or restrict, accounts that search heavily and rarely book. Caching, sensible form design and keeping bots away from your search page all help.

We go deeper on all three topics in flight API rate limits, caching and IP whitelisting.

How to evaluate a flight API

Before you commit engineering time, get clear answers to these questions:

• Coverage: which airlines and markets matter to your customers, and are they actually bookable, not just searchable?
• Content type: GDS fares, NDC offers, low-cost carriers, or a mix? Are private or negotiated fares available?
• Scope: search only, or search, booking, ticketing and post-booking changes?
• Pricing model: per search, per booking, a monthly plan with quotas, or a markup in the fare?
• Payment model: a prepaid balance you top up, a credit line backed by a deposit, or the traveller's card passed through to the airline?
• Accreditation: do you need your own, or do you book under the provider?
• Sandbox and documentation: can you read the docs and test realistic flows, including failures, before going live?
• Support: who answers when a ticket fails to issue or an airline changes a schedule?

Ask to see the documentation before you sign anything. A provider that explains its errors, limits and booking states clearly is usually one that handles them properly. When you are ready to build, our flight search API integration guide covers the work step by step.

Where IATA.co fits

IATA.co is a flight booking portal and a flights API for travel agents, agencies and developers. We do flights only. We are an independent platform and are not affiliated with the International Air Transport Association.

The account is free: you sign up, verify your email and top up a prepaid balance. Bookings are deducted from that balance, there is no credit line, and every movement appears in a ledger you can check at any time. In the browser portal you can search one-way and round-trip flights in economy, premium economy, business or first for adults, children and infants, and every booking is saved in your dashboard.

You do not need your own accreditation to book through the platform, because you book through us. You remain responsible for your customers and for the fare rules of what you sell.

For developers there is a REST and JSON flights API. Access is requested from the dashboard and approved by a person. After approval you receive an API key and the documentation. Keys only work from whitelisted server IP addresses, each plan sets monthly searches and requests per minute, and responses carry rate-limit headers.

A sensible path is to start in the portal, learn how fares and fare rules behave on your routes, and move to the API once you know what you want to automate. You can create your account today and decide later.

Try it with a free account Create a free IATA.co account to search and book flights in the browser, top up a prepaid balance when you are ready, and request API access from your dashboard when you want to build.