Introduction of the Terms of Use

We have done something we were supposed to do a long time ago: we have published proper Terms of Use for our API. From now on these terms will be applicable to everyone using our API, including existing and new subscribers. We understand it might be quite a boring read, but nevertheless, we encourage you to take some time to review the terms.

Most of the clauses are standard which you may find for many other APIs. Please be advised that continuing to use our API will automatically constitute your agreement with all the terms. If you do not agree to any of the terms for any reason, you are kindly requested to stop consuming our API.

Introduction of Flight Alert PUSH API

We’re introducing a new big feature: Flight Alert PUSH API. It facilitates the delivery of flight data in a fundamentally different manner. Instead of polling flight status or FIDS endpoint again and again in order to get data updates, you can now subscribe to a certain flight or airport and get notified automatically whenever an update occurs.

Currently, we support webhook notifications: upon subscription, you provide us a URL. Then, our system will be sending HTTP requests containing notification JSON-formatted data to this URL whenever a flight update occurs. URL has to meet certain requirements.

We support subscribing to flight data either by flight number or by airport ICAO code. This way you can receive updates regarding specific flights as well as all movements in specific airports.

We strongly encourage you to explore relevant documentation to become aware of all the details, limitations, and implications. The most important of them are:

  • Flight subscriptions have a limited lifetime (currently, 7 days). This is so because even a single subscription can generate a significant amount of notifications. In order to prevent over-use and/or abuse of API, we keep subscriptions time-framed.  However, any subscription can be refreshed before its expiration by making a relevant API call, thus prolonging its lifetime (see documentation).
  • Similar to FIDS or flight status endpoints, the availability of flight subscription notifications is subject to the same data coverage and quality limitations. Therefore, before subscribing, always ensure that a flight or an airport is receiving live or ADS-B updates. If a flight / an airport only has static scheduled data and never receives live or ADS-B updates, there is no sense in subscribing to it: you will simply waste your API calls quota! Read more on this and how you can ensure this in the description to Create webhook subscription endpoint and in Data Coverage guidance.

Pricing plans were also adjusted in order to incorporate Flight subscriptions / PUSH API as well as to re-balance the whole pricing system. If you want to make use of the new PUSH API, you need to resubscribe to the new versions of the pricing plans. 

Please be aware that we only include the creation and refresh of webhook subscriptions into pricing quotas, whilst deletion and retrieving information about an existing subscription is always free of charge on any plan. We also do not charge for notification calls.You can already try the new Flight Subscription / PUSH API in the RapidAPI playground.

Improved flight delay statistics, flight delay brackets and flight locations for FIDS

  1. We have updated our “Flight delay statistics by flight number” endpoint. Earlier delay records of the same flight number were grouped by origins and destinations. This way you could separately see how much the flight is delayed in each airport it departs from or arrives at. From now on, groups are as well segregated by scheduled hours. This way you can see separate statistics for the flights commencing at different hours. This prevents mixing the statistics when, for instance, the airline changes the schedule or when there are multiple flights with the same number commencing at the same airport on the same day. The hour is reflected in the additional property “scheduledHourUtc” in each item within the “origins” or “destinations” collection of the endpoint response.
  2. Moreover, each item of these collections now contains several additional properties, including the number of flights considered for calculation, period of calculation, and, brackets containing more detailed information about how many flights were delayed/early per specific delay range brackets (e.g. late from 15 to 30 minutes, from 30 to 60, etc.), so you can precisely say how many flights on this route were delayed within, for instance, not more than 30 minutes and compare it with the total number of flights commenced. This will allow you to draw conclusions regarding the recent punctuality of the flight with better precision. Brackets are currently experimental and likely to be adjusted in the nearest future.

    Statistics are available only for flights commencing at airports that have live updates data coverage.

    Please take a moment to review the updated documentation for this endpoint as well as try it in RapidAPI playground

One more change is for FIDS / Schedules endpoint. Now it contains the experimental “withLocation” parameter. If set to “true”, the system will attempt to retrieve the current location, track, speed, and pressure altitude for the flights returned in the response. It is applicable for flights currently en route and having either ATC call-sign, registration, or Mode-S ICAO 24-bit address known.

This feature is reliant on previously introduced ADS-B-based flight data augmentation as well as on the current ADS-B territorial range. The latter is generally wider than the per-airport ADS-B coverage mentioned on the “Data coverage” page, that’s why you may receive locations for flights in airports not necessarily having ADS-B feed active. However, location won’t be present if the airplane is currently out of range. The feature is purely experimental, can be slow, and may move to a separate endpoint in the future.

Please take a moment to review the updated documentation for this endpoint as well as try it in a RapidAPI playground.

Flight take-off and landing time &Runway detection based on ADS-B data, More flights, and status updates

We are continuing to expand capabilities related to analyzing actual flight tracks with reliance on community-maintained ADS-B data provided by third-party. Attentive users could have already noticed that for some airports AeroDataBox API has started providing:

  • Flight runway data, which we introduced as a response to requests of a few users to have some capabilities to help the analysis of actual / expected taxi time to/from the terminal:
    • Actual flight landing and take-off times.
    • Actual runway of departure or arrival (the runway from which a flight took off from or landed on).
      This is rather new and you won’t normally find this piece of information in other data sources. 
  • Extra flights and extra flight status updates:
    • Adding extra flights not normally available on online departure and arrival boards (we started to get more insight on the movement of cargo flights, corporate jets, general aviation, etc.).
    • Live flight status updates for airports without live flight status coverage (limited to actual departure time and status for departing flights and expected and actual time and status for arriving ones).

All these capabilities are based on automated analysis of the actual trajectory of aircraft in the vicinity of this or that airport based on transponder ADS-B data.  

The feature is currently in early-stage mode, so we are going to increase its precision and enable support for more and more locations in the upcoming weeks. We have this feature currently enabled for the following airports:  CYVR, CYYC, EBBR, EDDB, EDDF, EDDH, EDDK, EDDL, EDDM, EDDS, EDDT, EDDV, EDLV, EGCC, EGGD, EGGW, EGHI, EGKK, EGLC, EGLL, EGNX, EGPH, EGSS, EHAM, EHBK, EHEH, EHKD, EHLE, EHRD, EIDW, ENGM, EPKT, GMMN, HECA, KATL, KDFW, KEWR, KJFK, KLAS, KLAX, KLGA, KPHX, KSEA, KSFO, LEMD, LFBD, LFML, LFPG, LGAV, LICJ, LLBG, LMML, LPFR, LPMA, LPPT, LSZH, NZAA, OERK, PANC, PHNL, RCSS, RCTP, RJAA, RJTT, RKSI, SBKP, SBSP, SDAM, SEQM, SPJC, UAAA, UIII, UKBB, UKKK, UNEE, UNNT, UUBW, UUDD, UUEE, VHHH, VIDP, VOBL, VOMM, VTBD, VTBS, WIII, WMKK, YBNA, YMML, YPAD, YPPH, YSSY, ZUCK

Here you can also see statistics on how many flights (in absolute and relatively) had both runway and runway time detected: 

We’re also going to update health-check endpoints soon, so you will be able to check which airports have this supplement ADS-B data service operational.

Please be aware of the following limitations:

  • Limited coverage.
    We, unfortunately, won’t be able this feature available worldwide due to the absence of local contributors of ADS-B data to our third-party provider.
  • This extra data is currently not guaranteed to be always available or correct even if an airport is considered covered.

    Though the precision of the algorithm is rather high when the data quality is reasonable, the algorithm is still heavily reliant on the quality and availability of the external data, which is subject to a myriad of factors out of our control (unusual trajectory of the aircraft, transponder peculiarities of an aircraft, individual ADS-B receiver’s location, range and operational hours in the vicinity of the airport, overall coverage of the third-party provider). 
  • Naturally, this data will only be available retroactively due to how ADS-B operates. We only will be able to retrieve the data once the aircraft is departed, on approach, or arrived. There will be no significant look-ahead.

    This way, data may be partially unavailable because, for instance:
    – right after take-off an airplane has taken an unusual/sharp turn (due to ATC instructions, circuit pattern, weather, evasion maneuver, etc.) over an airport with multiple runways located close or unevenly (like, San Francisco or Amsterdam Schiphol) and the system is no longer able unambiguously “guess” the right take-off runway;
    – the only local contributor’s ADS-B receiver in the vicinity of the airport went down due to network or power problems -> no extra data will be available during this period of time, despite normally it is.
    – etc.

Please feel free to try it and don’t hesitate to report any bugs.

Searching for Flight Status by ATC Call-sign, Aircraft Registration or Aircraft 24-bit ICAO Mode-S transponder address

We are introducing more capabilities to search for flight status. 

From now on, you can look for individual flight information not only by flight number but also by ATC call-sign, registration or 24-bit ICAO Mode-S hexadecimal transponder address of the aircraft operating the flight. 

New search capabilities are delivered by introducing new endpoints: 

  • Flight by aircraft registration (and date) 
  • Flight by ATC call sign (and date) 
  • Flight by ICAO 24-bit Mode-S address (and date) 
  • Flight departure dates by aircraft registration (within range) 
  • Flight departure dates by ATC call sign (within range) 
  • Flight departure dates by ICAO 24-bit Mode-S address (within range) 

The behavior, contracts, and pricing of each of the new endpoints remain the same as for similar endpoints operating based on flight number.

Please feel free to try it and don’t hesitate to report any bugs.

Adding USA Live Flights Coverage, Adding Mode-S Transponder Code, COVID-19 Changes, Airport Daily Statistic Routes Update

Here are some updates regarding the API made in recent weeks:


We have integrated live flight updates for the airports in the USA, which is a huge live flight data coverage expansion (almost 400%). Updates are based on flight plan data and include aircraft registration and model, flight status, scheduled, estimated and/or actual times.


We started storing Mode-S Transponder ICAO 24-bit identifiers for flights when possible. It’s populated either from ADS-B data or from aircraft registration (based on aircrafts database look-up). You can already see this information when requesting our FIDS or Flight Search endpoints.


We’re experimenting with analyzing flight trajectories based on ADS-B data to provide more live flight updates based on this. This way you may observe more and more particular flights having updated times and statuses even if an airport is not marked as an airport having live flight updates.


The situation around COVID-19 is unprecedented and it has a dramatic effect on aviation traffic (we observe up to 80-90% traffic decrease in certain areas). We also had to adjust our algorithms extensively to deal with the growing degree of ambiguity and incompleteness of incoming information about flights.

The biggest impact is on the flight seasonal schedules. If you check flights scheduled in the future, you may notice that information is less reliable than normally due to numerous cancellations made by airlines these days. 

But there is a difference between ad-hoc flight cancellation and systematic seasonal schedule change. What’s happening these days looks like a great many ad-hoc cancellations which, because of their quantity, seem like legit schedule changes. Airlines say: “we cancel all our flights because of COVID restrictions”, and for us, it sounds like a big schedule change. But it’s technically a batch of ad-hoc cancellations, just a very big one. It’s not a change in pre-planned seasonal schedules, which you see when you pull data from the API with more than a few days look-ahead (these flights have “Unknown” status). This data may or may not be augmented with live status data (incl. cancellation status) later. But it may be that many of the flights you see now in schedules will be canceled while COVID restrictions are in force.

However, even live data is inconsistent these days. Normally when a flight is canceled we receive a flight with valid “canceled” status. However, these days it’s more and more often that a flight may just disappear unexpectedly from the list a few hours before departure/arrival time and we don’t know if it has been canceled or it should never have been in schedules in the first place and we should also remove it as well. It’s also possible that canceled flight continues to be reported as planned with no time change even after flight departure/arrival time has lapsed. 


To address this and a few more ambiguity issues, “CanceledUncertain” flight status was introduced. This status will be assigned to flights that have been likely canceled. There is a complex technical background behind the assignment mechanisms, but it’s essentially based on the expectation to receive an update for a flight and failure to do so. Please be advised, that though status is likely to be assigned correctly, there is still a chance that the “likely canceled” flight has actually departed/arrived.

You can get flight status together with other flight information when requesting our FIDS or Flight Search endpoints.


In light of numerous COVID-related cancellations, we adjusted the airport daily route statistics endpoint to calculate statistics based on flights that actually commenced (canceled and likely canceled flights are now excluded) – this will give a much clearer picture of the current situation.

FIDS with Extended Information, Flight Time and Distance

There weren’t many updates recently. Due to independent personal circumstances, we can’t devote much time to developing AeroDataBox at the moment, unfortunately. Nevertheless, there is some new stuff in the API:

  1. FIDS endpoint now has additional query string boolean parameter “withLeg”. When set to true, the response will contain times of arrival at destination for departing flights, and times of departure from the origin for arriving flights, if available. Please note, that the response contract will change slightly in this case. Feel free to check this endpoint out in the sandbox (  ) and review extended documentation ( ).
  2. Endpoint for calculating distance and flight-time between airports (by IATA or ICAO codes) is added. It requires a pair of ICAO or IATA codes of airports as input and returns great circle distance and estimated flight time between these airports. Flight time evaluation is based on re-calculating the great circle distance against the statistical duration average of multiple flights that covered similar distances before. This interpolation approach gives a more precise estimate of possible flight time rather than just dividing distance per some constant average speed. Feel free to check these endpoints out in the sand-box:

and review extended documentation:

New Year Updates

Dear users,

We have several updates:

  • [NEW] “Search airports by location” endpoint is added. It allows finding airports situated within a certain radius around the location specified. More:
  • [NEW] “Airports supporting data feed service” health-check & status endpoint is added. It’s designed to get a list of ICAO codes of airports for which we have a certain flight data feed service operational at the moment. To get the list, you need to specify which service type you’re looking for. FlightSchedules – information about scheduled flight times. FlightLiveUpdates – live flight status and time updates. This may be useful for you to know what is the overall data coverage without the need to check each airport feed individually. Calling this endpoint is at all times free. More: 
  • [UPD] Both flight status endpoints now have the optional query string parameter “withLocation” (“false” by default). If set to “true”, API will attempt to fetch real-time positional data of the flight (location, speed, track, altitude) if it’s airborne, if it has call-sign mapped (more on this below) and if ADS-B data is available for this flight now. More:  and
  • [UPD] “Departures and arrivals (FIDS) by airport ICAO code” endpoint now supports getting departures or arrivals separately. Please review the new “direction” parameter. More:
  • [UPD] Live flight data is now generally populated with more passenger-related items: terminal, check-in desks, gate, baggage belt. The presence of this data is subject to availability in the data source.
  • [UPD] Live flight data is now enriched with real-time ADS-B data more often: much more live flights now have registrations and ATC call signs mapped once these flights are airborne. There is more to be done on this, though: the main obstacle here, besides obviously limited coverage of AeroDataBox flight data and ADS-B data, is that call signs and flight numbers don’t always match, so these items have to be correlated using different approaches, incl. analyzing routes, aircraft, and flight schedules, TBD.
  • [UPD] More airports now have a schedule and live updates flight data feeds now.

… and also a few recommendations:

  • When specifying any boolean parameter in any endpoint, please use “true” or “false”, not “1” and “0”, EVEN if the RapidAPI example states the opposite. Recent changes in the RapidAPI provider dashboard are forcing me to enter “1” or “0” when updating API endpoint documentation. And while it’s working perfectly from the provider dashboard, it doesn’t work from the marketplace for some reason. 
  • RapidAPI sometimes generates faulty code snippets. So, review them carefully before use. Review this discussion recently initiated by our users:
  • Always check our API website for more documentation. RapidAPI has limitations on what information can be published in the marketplace. For instance, they don’t support having documentation for response properties.

… and one more remark:

AeroDataBox API project was created a few months ago as a proof of concept of a freemium/low-cost API with limited data coverage for smaller projects. Since this little time, a few pros and cons were observed: we are seeing some demand, but also observing some misuse. Pricing plans and API usage quotas probably will be reviewed: we want to stay available for smaller projects, but we also cannot handle too many users shooting dozens of requests per second apparently in an attempt to download our database as whole 🙂

Anyway, everything is in active development now, mostly not visible outside. There are much more plans than could possibly be handled, therefore choices will be made to grow only in the most realistic directions. Any help, contributions, or suggestions are greatly appreciated. 🙂 

Happy New Year!

Airport Runways and Airport Routes Daily Statistics

A few more endpoints were added to the AeroDataBox API:

1) Airport runways by airport ICAO

Runways data was revised and updated for airports currently existing in the database. Therefore, data about heading, surface, width, threshold position, displacement, and operation of the runways are available. You can also get runway information (as well as local time) in addition to basic airport information using regular ‘Airport by IATA’ or ‘Airport by ICAO’ endpoints, so you don’t have to shoot two calls.

2) Airport routes daily flights statistics by airport ICAO

This endpoint exposes statistical information for airports where we have static schedules or live flight updates enabled. Statistics are meant to answer the following questions:

  • What are the most popular routes from an airport?
  • Where I can fly from an airport?
  • How many daily flights to different destinations from an airport?

Endpoints are now available on RapidAPI with a bit more readable and extensive documentation located here: 

Thanks for using AeroDataBox API!

Flight Status & Schedule, Flight Delay Statistics, FIDS, Airport Delay Index

We’ve been recently busy adding a few more endpoints to the AeroDataBox API. Now you are able to:

  • Get flight status or schedule for a specific date as well as for the nearest flight;
  • Get flight delay statistics;
  • Get departures and arrivals list per airport and within a given time range (FIDS);
  • Get current airport delay statistics (delay index).

 In addition, fixed a few major bugs in data aggregation, which should increase data quality. And also, many flights with live updates are now having registrations of actual aircraft operating these flights.

There is currently no limitation on date time ranges you can request the information (no matter how much data is kept in the system, you are currently able to access it all). But, keep in mind, however, that live flight update information is yet available for only a few hundred airports mostly located in Europe. As demand for API will grow, coverage will be increased. Static flight schedule information, however, is available to a much bigger extent.

Also, I have expanded the overall description of the API and detailed documentation, which can be found here:

Thanks for using AeroDataBox API!