FAQ

AeroDataBox is a niche aviation and flight data API with certain openly communicated limitations. When it comes to our services, we generally try to under-promise and over-deliver. In fact, at times our service may exceed those of other more expensive providers. But is a niche API good for your case? That depends!

This API is originally built with the idea of supporting smaller applications teams, researchers, individual developers, and anyone else who cannot afford hefty charges imposed by market-leading data companies but who are also OK with having less in terms of data precision, coverage, and service stability in exchange. So, if you're developing a small or medium application that does not have top-level demand for data quality and does not require SLA, our API might be just right for you, because it:

• is offered at symbolic rates with the lowest one being comparable to a cup of coffee (see pricing);
• has some unique features which are not offered anywhere else or offered at higher rates (airport and flight delays API, airport routes statistics, take-off/landing runway detection, realistic flight-time calculations, FAA LADD aircraft status, etc.);
• means supporting smaller enthusiastic projects rather than bigger corporate products;
• is easy to integrate with, not complicated in use and well-documented.

However, you currently are discouraged (and even not allowed in some cases) to use our API for mission-critical products, especially if your product is involved with real-life aircraft operations or navigation.

We are doing our best to achieve the best API uptime possible. Our current uptime metrics can be seen here.

We do not provide any service level guarantees at the moment, but hope to start providing them soon.

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.

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.

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?”.

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.

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.

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.

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.

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.

Yes — direct subscriptions are now available through our portal, with no middlemen involved. Choose “Directly with Us” among the ways to subscribe to see the direct plans. For unlimited or custom plans, we may provide direct access subject to an extra fee and a separate service agreement. Contact us for details.

There are currently three available options:

1. Try flight search on this web-site which is powered by our API where you can search individual flights as well as flights per airports through your browser.
2. Subscribe to our API on one of the supported marketplaces via a free or trial pricing plan. These plans have limited quota but also have all data available on higher pricing plans, so it gives a great idea of what the data may look like.
3. Subscribe to our API directly with us through our portal and earn API credits by contributing data. Note: these credits apply to direct API access through our portal only (not to marketplace subscriptions!). They do not expire, and let you call the API even without a subscription.

There are two options available:

1. Subscribe to our API on one of the supported marketplaces via a free or trial pricing plan. These plans have limited quota but also have all data available on higher pricing plans.
2. Subscribe to our API directly with us through our portal and earn API credits by contributing data. Note: these credits apply to direct API access through our portal only (not to marketplace subscriptions!). They do not expire, and let you call the API even without a subscription.

Each API endpoint has different technical and computational complexity. We price endpoints based on that by assigning them a certain category — a Tier. The higher the Tier number, the more expensive a call to the endpoint will be. You can find which endpoints belong to which Tier in our documentation. Note, that this is not the same as an endpoint group (Flight API, Aircraft API, etc.) and a single group may contain endpoints from various Tiers.

• API request (call) — a single HTTP call to one of our endpoints. May cost one or more API units.
• API units — the monthly quota included with your subscription plan. Each request deducts a number of units defined by the endpoint's Tier. Unused units reset at the end of each billing cycle.
• API credits — a non-expiring balance available with direct access only (not on marketplaces). Credits are consumed at the same rates as API units, but only after your monthly API units run out — or when you have no active subscription. You can earn them by contributing data.
• Flight Alert credits — a separate non-expiring balance used exclusively to pay for Flight Alert API notifications. It is refilled through the API by converting API units into credits. See the Flight Alert API guide.
• Overages — pay-per-use billing of API units consumed beyond your monthly quota, supported on selected plans only. Overage charges start only after both your monthly API units and API credits (if applicable) are fully spent.

Once monthly API units included with your plan are exhausted:

1. Your non-expiring API credits (if you have any) are consumed automatically, at the same rates as API units. This option is only available for direct subscriptions with us, not through 3rd-party marketplaces (RapidAPI or API.Market).
2. If API credits are depleted or unavailable, overage billing begins (only on plans that support overages).
3. If overage billing is unavailable, further API calls are rejected until your quota renews at the next billing cycle or until you re-subscribe.

You can earn extra API credits by contributing data.

That depends on what is being changed and how you subscribed to the API.

If you subscribed to the API through a 3rd-party marketplace (RapidAPI or API.Market), changes like monthly subscription prices, quotas, rate limits, overage pricing or included endpoints are governed by the marketplace's terms and pricing plan management mechanisms. From what we observed, both RapidAPI and API.Market currently enforce a grandfathering principle. This means that when we as an API provider change aforementioned parameters through their platform, a new version of the pricing plan is created that will only apply to the new subscriptions, leaving existing subscriptions unaffected. This means that these changes won't affect you until your re-subscribe to this plan.

However, certain billing-related changes, like moving an individual endpoint to a different Tier or the API unit billing of individual endpoint calls are dependent on what our API backend reports to the marketplace gateway at the time of the API call using special headers. Therefore if we make the changes to the headers on our backend, it will affect calls made from all marketplace subscriptions, new ones and old ones alike. We avoid such changes as much as possible, but if we implement them, we announce them well in advance.

If you subscribed to the API through us directly, we will generally follow the same grandfathering principle to avoid any alterations for existing subscribers. However, we reserve the right to apply any pricing plan changes to existing subscriptions either on the next billing cycle or at a specific previously announced date.

Another group of changes that may affect your active subscription indirectly regardless of the subscription method, are the changes to the terms of use / plan terms. These changes are non-technical in nature and do not affect billing. However, they may affect your rights and obligations as a user. Likewise, we keep such changes to a minimum and announce them in advance.

To receive updates about pricing changes, please subscribe to our newsletter.

We recommend checking our terms of use for detailed information on caching, attribution and other requirements (specifically, Article 5). Please note that your specific plan may have customizations, so be sure to review the conditions published for each pricing plan on the pricing page.

Only when you let a third party work with the data inside your Derived Work, rather than just use the result you built, on a commercial basis (i.e., if you charge a fee for this service, or if your customers are licensed to charge a fee based on your Derived Work). This mostly comes up in commercial B2B arrangements, where your customers or partners are themselves businesses that build on what you supply using our API. The test is whether the deal ends with your customer (End Use), or lets them take the data-derived content further and possibly monetized it.

You do not need it when others only consume a finished result (End Use). E.g.:

• You create a mobile application displaying flight number, time, status and gate of departure. User refers to it to check on their flight.
• You sell a monthly PDF report of on-time performance by route. The airline reads it.
• You run a paid dashboard showing delay statistics you computed. Users log in and look at the numbers.

You do need it when a business customer or partner can take the data-derived content and build on it themselves. E.g.:

• Your customer can query your enriched dataset and export the records into their own system to power their own product.
• You license your derived dataset to a software vendor who embeds it in their platform and resells access to their customers.
• You give a partner a data feed they’re allowed to redistribute or re-license onward commercially.

Rule of thumb: if the deal ends with someone using the result, it’s a sale — allowed on any paid plan with commercial use rights (currently - any paid plan), no special setting needed. If a third party can extract, redistribute, or re-license the data-derived content to build their own products, and you charge them for it, that’s sublicensing, and it requires a plan that includes Derived Work sublicensing.

This applies only to genuine Derived Works — your own analysis or computed output. It never covers passing on our raw data or API access; see “Can I resell your API or any data from it?”

This does NOT apply when you provide access to the Derived Work for free and your customers use it for their own purposes without commercializing.

No — on any plan, free or paid. You cannot give, sell, or pass any third party access to the AeroDataBox API or to the data it returns. Examples:

• Reselling your API key or letting another company call the API through your subscription. → Not allowed.
• Republishing the raw API responses, or a copy of them, as a dataset, feed, file, or database others can pull from. → Not allowed.
• Building a service that lets third parties query our data through you — an API in front of our API. → Not allowed.
• Handing over lightly changed data — reformatted, translated, or with fields renamed — since that's still our data, not your own analysis. → Not allowed.

If you subscribed through a 3rd-party API Marketplace (RapidAPI, API.Market): these marketplaces are managing subscriptions, billing and payments for us and do not allow us to initiate refunds and any subscription/billing-related operations. So, as an API provider we cannot fix issues related to marketplace billing. You need to contact the support team of the marketplace you used to subscribe to our API to resolve your issue.

If you subscribed directly through our portal, contact us.

• RapidAPI: rapidapi.zendesk.com/hc/en-us/requests/new
• API.Market: api.market/contact

If a link above is not working, check the web-site of the marketplace you used to subscribe to our API and see which is the current preferred option to reach out to them.

You are always welcome to send us your suggestion! We regularly make adjustments and introduce new features into our API based on the feedback received from the users. However, we cannot always guarantee that your feature will be implemented (soon): unfortunately, not all things are possible or achievable within a reasonable amount of time and effort. We have as well a long backlog of items to work on, and there might be more critical things awaiting there.

You may as well contact us if you don't want to wait or if you're looking for a custom solution to be implemented for you on a paid basis. Depending on our availability and your budget and requirements, we might be able to discuss possible options.