What is the Coverage?
We cover the majority of commercial flights worldwide. Coverage limitations are determined predominantly on a geographical basis (per airport / region, rather than per airline), as well as by the limitations of the external data sources. As an enthusiast-driven API, we deliver flight data in the best effort fashion, which is why worldwide coverage and precision of data is not guaranteed. In exchange we charge a fee which is significantly below the market average with the lowest paid plan comparable to a cup of coffee. More about this can be found in our FAQ.
Check out our flight search to try some flight data available through AeroDataBox API.
The Structure of the Flight Data Coverage
Each flight returned by the API is composed of up to 3 data “layers” applied and merged on top of each other: schedules (static data), live (dynamic) data and ADS-B data. Given this and the geographical nature of the coverage, each flight may therefore have a different degree of coverage for departure and arrival pieces of the information (asymmetrical coverage).
Example of asymmetrical coverage. A flight departing from an airport in the area with all 3 data layers operational and arriving into an airport with only the schedule data layer active, will have live status updates for the origin airport (ETD, ATD, possibly gate number, check-in desk, aircraft registration), and only scheduled time available for the destination (consequently, this flight may not go past the “departed” status, because it will never get an actual arrival status report). Please note, that sometimes, a flight or part of the flight (departure or arrival) may have no coverage at all!
Let’s look into data layers which compose the final flight data you get from the API.
Layer 1. Schedules / Static Data
This data layer is static and therefore doesn’t include any status updates and doesn’t reflect the actual progress of a flight. Often, it provides a significant look-ahead for the upcoming flights. This data layer includes basic minimum information about a flight:
- flight number (always);
- airline (always);
- planned time of departure / arrival (always);
- destination / origin (always);
- planned aircraft type (often);
- terminal (sometimes).
As flight schedules do not provide live status updates, the status for a scheduled flight will stay “Unknown”, and planned times will stay the same as revised times, until the flight is updated by the other data layers, if available (see below).
Current Schedules (Static) Data Configuration
- Updated: once in 2 weeks per airport / region
- Available: up to 365 days¹ in the future, if available²
- Historical data is available: up to 365 days in the past, if available²﹐³
¹ Depends on your selected pricing plan. ² May effectively be less for specific flights, airports, regions depending on the quality of the contributing data sources and depending on how far in the future airlines publish their schedules. ³ Do you need more historical data? Please contact us.
Layer 2. Live / Dynamic Data
Data from “live” update feeds layer complements / overwrites schedules data in accordance with the actual progress of the flight, by adding the following information:
- revised planned time of departure / arrival (always);
- actual / estimated time of departure / arrival (always);
- status of the flight (always);
- revised aircraft type (often);
- code-share marker (often);
- terminal (sometimes);
- check-in desks (sometimes);
- baggage belt (sometimes);
- gate (sometimes);
- cargo marker (sometimes);
- aircraft registration (sometimes);
- aircraft ICAO Mode-S 24-bit address (sometimes);
- ATC call-sign (rare);
- actual / estimated time on the runway: take-off/landing time (rare).
This layer is dynamic and is updated frequently. It covers the data related to the estimated and actual progress of the flight. It may also create new flights if not previously provided by the scheduled data layer or remove flights that were placed into schedules incorrectly.
Current Live Data Configuration
- Updated: with variable interval, typically from nearly real-time up to once in a few hours
- Available: variable, from a few hours ahead up to a few days ahead, typically up to tomorrow¹
- Historical data is available: up to 365 days in the past, if available²﹐³
¹ May effectively be less for specific flights, airports, regions depending on the quality of the contributing data source. ² May effectively be less for specific flights, airports, regions depending on the quality of the contributing data source. ³ Do you need more historical data? Please contact us.
Layer 3. ADS-B Updates Data
Experimental data layer. This information is derived by analyzing data retrieved from ADS-B receivers located worldwide. This, among others, includes positional changes of the aircraft operating the flight. It may complement scheduled and/or live update data with the following information:
- ATC call-sign (always);
- aircraft registration (always);
- aircraft ICAO Mode-S 24-bit address (always);
- revised aircraft type (always);
- actual / estimated time on the runway: take-off / landing time (sometimes);
- actual / estimated runway of take-off / landing (sometimes);
- actual / estimated time of departure / arrival (sometimes).
This type of layer / feed may also create new flights if those were not mentioned in other data layers (typically applies to general aviation or cargo flights). This information is dynamic and updated frequently: with an interval of from a few seconds up to half an hour. Due to the nature of ADS-B, this data is optional even in the areas with stated good coverage. This layer is naturally real-time only and does not provide any look-ahead in the future.
Uniformity of Limitations
You may retrieve flight information either by requesting a specific flight individually, or by listing flights per airport, or by requesting flight updates using the subscription mechanism of our PUSH API. Either way, all coverage limitations apply to any relevant flight data endpoints.
Furthermore, flight data coverage restrictions equally affect any functionality and data derived from the flight data. For example:
- there will be no airport or flight delays statistics available for flights / airports without historical live or ADS-B data coverage;
- Flight Alert PUSH API will not provide any updates for flights departing from / arriving to airports / regions without stable live or ADS-B data coverage: there is no practical sense to subscribe alerts to such flights or airports;
- could be more (see API specification for the list of endpoints).
Coverage Questions
Common questions about coverage, data quality and what we can fix. More in the full FAQ.
Are there any limitations?
Yes, and we communicate them openly. They come in two kinds:
- Data limitations — coverage is extensive but not worldwide, and the completeness of a flight depends on the airports and the region it touches. See data coverage.
- Usage limitations — what you may do with the data (caching and retention, attribution, resale, sublicensing) follows from our terms and from the plan terms of the subscription you choose on the pricing page.
Do you have worldwide coverage for flights? Which regions are supported?
We cover the majority of commercial flights worldwide, but coverage is extensive rather than complete. It is determined predominantly on a geographical basis — per airport and region, rather than per airline — and it inherits the limitations of the external sources we aggregate.
The coverage map and the coverage-by-country table on the data coverage page show where we stand. Both are updated manually at irregular intervals and give a general idea only: for the current state of a specific airport's feeds, use the health-check and status API.
What data quality can I expect?
All contents are aggregated from third-party suppliers, providers and contributors, and delivered in an enthusiast-driven, best-effort fashion at rates below the market average. Data may be delayed, incomplete or inaccurate, and precision is not guaranteed. We normalize, correct and augment what we receive, but we cannot produce what our sources do not provide.
Note that our API is not a substitute for official or government aviation data sources, and safety-critical use is not permitted. Whether the trade-off suits your project is covered in “Is it good for my case?”.
Why does one flight have live status, gate and registration, while another only has a scheduled time?
Each flight is assembled from data from various data sources stacked on top of each other. Each data source could be attributed to one of the following categories (layers of data):
- Schedules — static data published in advance: flight number, airline, planned times, origin and destination. It reaches furthest into the future, but never reflects the actual progress of a flight.
- Live feeds — revised and actual times, flight status, and often gate, terminal, belt, aircraft type or registration. This layer may also add flights the schedules missed, or remove ones scheduled in error.
- ADS-B — derived from receivers worldwide: call-sign, registration, Mode-S address, and sometimes take-off/landing times and runways. Real-time only, and optional even where coverage is otherwise good.
A flight shows only what the layers available to its airports and region can supply. Because coverage is geographical, departure and arrival of the same flight may be covered differently: a flight can receive live updates at its origin and nothing but a scheduled time at its destination — and consequently never progress past “Departed”. The field-by-field breakdown of each layer is on the data coverage page.
How far into the future and into the past does flight data go?
That depends on the data layer and on your pricing plan:
- Into the future — schedules provide the look-ahead, and how far ahead is capped by your plan. Live feeds typically reach only about a day ahead, and ADS-B provides no look-ahead at all.
- Into the past — historical flights, and everything derived from them (statistics, delays), are available for the period included in your plan.
The current windows per layer are listed on the data coverage page, and the per-plan limits in the plan comparison on the pricing page. Need more history than your plan allows? Larger historical datasets are available on demand — contact us.
Does coverage also affect delay statistics, alerts and other derived data?
Yes, uniformly. Coverage limitations apply to every flight data endpoint alike — whether you request a single flight, list flights per airport, or subscribe to updates through the PUSH API — and they equally affect everything computed from flight data. For example:
- no airport or flight delay statistics are available for airports without historical live or ADS-B coverage;
- the Flight Alert API produces no updates for flights departing from or arriving at airports without stable live or ADS-B coverage, so subscribing to alerts there has no practical use.
The same holds for other derived endpoints — see the API specification for the full list.
My flight is missing or has partial data. Why is that? Fix it immediately!
Coverage limitations are geographical: if the airports or the region your flight touches are uncovered, or covered by only some of the data layers, the flight may be missing or partial. All data reaches you the same way it reaches us. As a budget API we cannot reasonably provide every single flight possible, and we have no capacity to chase and investigate every missing flight reported to us. In the rare cases where we can, there is usually not much we can do to fix it. That is the reality of this industry, and many other providers experience similar problems to a bigger or lesser degree.
While we do our best to normalize, correct and augment the data, we cannot make it up or force providers and contributors to provide it to us. Coverage issues are resolved through consistent expansion and technical improvement work, which we perform diligently — but that is not something that can be done on demand / “urgently” for your specific project, and definitely not at our current pricing rates.
What does help is telling us which area you need. Areas with more votes are eventually prioritized on our roadmap, and requests from customers on high-tier or custom plans, or from those contributing their own data, may be prioritized as well. Contact us to put your area forward.
Can I contribute my data? Can we have a partnership?
We are on a constant look-out for more and better sources of data, so the short answer is — yes. You can feed us your ADS-B data by following the contribution guide: it helps us expand live and ADS-B coverage, and earns you non-expiring API credits in return.
For anything beyond that — data exchanges, partnerships or custom arrangements — the longer answer depends on the details of the proposition, so please contact us.