The first version of every flight integration looks the same: take the flight number from the booking, call a status API, show the result. It works in the demo. Then a customer flies TK1 on a day it operates two different legs, or books UA8841 and boards a Lufthansa aircraft, and the screen shows the wrong flight with complete confidence.
Choosing a flight API matters, but most of the pain comes after the choice. This article covers both: first the eight APIs worth knowing in 2026 and what each one is best at, then seven mistakes that break flight integrations whichever one you pick.
The short list
“Flight data” is really four products: airline status (times, gates, delays), aircraft positions, catalogues of airports and schedules, and history. Pick by the job your product does.
- Alerts when a flight changes: FlightByte
- Depth, tracking and history on a company budget: FlightAware AeroAPI
- Live aircraft positions: Flightradar24 API
- Enterprise status data under contract: Cirium (FlightStats)
- A cheap, broad catalogue: AeroDataBox
- Many requests at a low price: AirLabs
- The quickest start for simple lookups: aviationstack
- Free data for research and non-profit work: OpenSky Network
One name is missing that older lists still include: Amadeus closed its Self-Service APIs on July 17, 2026, and developers can now reach it only through an enterprise contract.
The eight APIs, briefly
FlightByte: best for flight change alerts. FlightByte is a flight status API built around webhooks: you subscribe to one flight on one date, and every change reaches your server as a signed event with the old and the new value, whether it is a gate, terminal, delay, departure, landing, baggage belt, cancellation or diversion. It charges per watched flight rather than per request, from $9 a month for 100, and its free tier of three flights a month is the only one on this list that allows commercial use. It has no aircraft positions and no history.
FlightAware AeroAPI: best for depth. Positions, tracks, airport boards, history and alerts, priced per result set. The Personal tier gives $5 of free usage a month for personal projects; business use starts at a $100 monthly minimum. Its alerts cover lifecycle moments such as departure and arrival, so gate and delay changes still mean polling.
Flightradar24 API: best for live positions. Positions every few seconds from Flightradar24’s own receiver network, plus tracks and, on larger plans, years of history, paid in credits from $9 a month. It has no schedules, gates or delays, and it pushes nothing.
Cirium (FlightStats): best for enterprise contracts. Status by flight, airport and route, push alerts with typed rules, and status history back to 2006. A 30-day evaluation is free; the features most products want, alerts included, sit in its Contract plan.
AeroDataBox: best for a cheap catalogue. Flight status, airport schedules by date range, aircraft data and up to a year of history, from $19 a month direct or less through a marketplace. Its alert API works on a best-effort basis.
AirLabs: best for volume. From $49 for 25,000 queries to $499 for a million, with aircraft positions included and an alert API in beta. As of October 2026, new sign-ups join a waiting list.
aviationstack: best for a quick start. One key and a simple REST interface, with 100 free requests a month for non-commercial use and $49.99 for 10,000 after that. It has no webhooks.
OpenSky Network: best for research. Free ADS-B positions and flight histories for personal and non-profit use. Commercial use needs OpenSky’s consent, and there are no schedules, gates or delays.
What breaks after you pick: seven mistakes
None of these depends on the provider. They come from how airlines publish data, and every integration meets them in its first busy month.
1. Treating a flight number as a flight
A flight number is a label an airline reuses every day, and sometimes twice on the same day: Turkish Airlines’ TK1 has operated two legs on one date, one to Amsterdam in the morning and one to New York in the afternoon. Codeshares stretch it the other way: on October 25, 2026, the ticket number UA8841 was Lufthansa’s LH400 from Frankfurt to New York. Identify a flight by carrier, number, date and departure airport, and when two numbers turn out to be one aircraft, keep one record for both.
2. Using the wrong date
Flight dates are local to the departure airport. UA1 leaves San Francisco at 22:40 on October 25 and reaches Singapore at 07:00 on October 27, local time, and it is the flight of the 25th throughout. Store the date the airline uses and convert times only for display. A server running in UTC that “corrects” the date will quietly look up the wrong day’s flight.
3. Showing the wrong time
A flight can carry three versions of each time: scheduled (the timetable), estimated (the airline’s current expectation) and actual (what happened), at the gate and on the runway. Estimates move in both directions: on October 26, 2026, TK1’s estimated departure from Istanbul went from 14:45 to 14:35 and back to 14:45 within about six hours, without the flight ever running late. Show the best time you have, actual if it exists, then estimated, then scheduled, and label it. “Departs 14:45” means one thing when 14:45 is a promise and another when it is a fact.
4. Alerting on every delay update
Airlines rarely announce a delay once. A forty-minute delay often arrives as ten, then twenty-five, then forty, and sometimes falls back to thirty. An app that pushes every step gets muted; one that waits for the final number tells people too late. Set a threshold, send the first change that crosses it, and stay quiet about small movements after that.
5. Treating the first gate as final
Gates are often published well before departure: UA1’s gate appeared in United’s own timeline more than a day ahead. A gate published that early is a plan, and it can change right up to boarding, especially at busy hubs. Treat every gate as current rather than final, and make a new gate replace the old one on the user’s screen instead of arriving as a second, contradictory message.
6. Confusing “landed” with “arrived”
Touchdown is not the end of the flight. The aircraft still has to taxi to the gate, and the bags come out later still. A driver dispatched at touchdown waits at the curb; one dispatched at gate arrival is on time; and the baggage belt number is what meet-and-greet staff actually need. Use the phase the data gives you, landed or arrived, and act on the one that matches the person who is waiting.
7. Polling to find out that nothing changed
The default integration is a loop: ask about each flight every few minutes, compare the answer with the last one, act on the difference. Checking every five minutes for the last six hours of a flight is 72 requests, or 36,000 a month for 500 flights, and most of those answers say nothing new. On a request-priced API you pay for each one, and you still own the scheduler, the comparison, the retries and the log. If your product reacts to changes, an API that pushes them is cheaper and simpler. If you do poll, poll slowly while a flight is days away and quickly only around departure and arrival.
Which API for which product
| If you are building… | Pick | Why |
|---|---|---|
| An airport transfer or chauffeur service | FlightByte | One subscription per pickup. A webhook when the flight slips, lands and reaches the gate, with your booking reference in every delivery. Dispatch on gate arrival, not on touchdown. |
| A hotel arrival desk or airport shuttle | FlightByte | A delay threshold, say 30 minutes, so the front desk hears about the late guest once, and the shuttle hears when the aircraft is at the gate. |
| A travel or itinerary app | FlightByte, plus a catalogue if you show airport boards | Watch each distinct flight once and fan the alert out to every user on it. Gate, delay and baggage-belt pushes, and a Live Activity from the same event. |
| A travel agency or concierge service watching clients’ trips | FlightByte with its n8n templates | Email, SMS or WhatsApp to the client and the agent when a flight changes, without writing a backend. Free for three flights a month to try it on real bookings. |
| An AI travel assistant | FlightByte’s MCP server | Flight lookups and alerts as tools in Claude, Cursor and VS Code, with no glue code. |
| A flight search or booking site | None of these for fares | Fares and tickets come from a booking API such as Duffel. After the booking, status from FlightByte or Cirium. |
| An airport arrivals screen | AeroDataBox or Cirium | Whole-airport schedules by date. FlightByte watches individual flights, not airports. |
| A flight map or spotting app | Flightradar24, or OpenSky for non-commercial use | Positions, not airline status. |
| Aviation analytics or on-time statistics | FlightAware AeroAPI or Cirium | Years of history. FlightByte keeps a live window only. |
Many production systems use two: a catalogue or a map from one provider, and the status of the flights customers are waiting on from another. Each vendor’s plans, free-tier limits and exactly what it pushes are in this full comparison of flight data APIs, which is kept up to date.
Disclosure: the author works on FlightByte. Figures for the other APIs come from each vendor’s own pricing and documentation, checked in October 2026.
