adsbdb: Intelligence Source Guide

adsbdb is a free, keyless API that turns a 24-bit ICAO hex address or a registration into aircraft type, operator and registered owner, and a callsign into a probable route. It is the resolution layer that makes raw ADS-B legible.

At a glance

Source	adsbdb
Category	Aviation & Space › Aircraft, Airports & Safety
Homepage	https://www.adsbdb.com
Machine interface	`https://api.adsbdb.com/v0/`
Format	`JSON`
Access	Open — no account required
Disciplines	Aviation Intelligence
Mission domains	Aviation Security

Free no-auth public API resolving ICAO hex/registration to aircraft details, callsigns to flight routes, and airline data. — as catalogued in the platform’s own source registry.

adsbdb is a small, open-source public API maintained by an independent developer, written in Rust and served without authentication. It answers three questions. Given a Mode S hex address or a registration, it returns the aircraft: type designator and plain-language type, manufacturer, registration, the registered owner and the owner's country, an operator flag code, and links to aircraft photography. Given a callsign, it returns a flight route: the airline associated with the callsign, and origin, optional intermediate and destination airports with their ICAO and IATA codes, names, municipalities, countries and coordinates. Given an airline code, it returns the airline's identifying details including its radio callsign. The underlying data is compiled from open aircraft and airport datasets that circulate in the ADS-B community, rather than collected first-hand, and the project is transparent that it is a convenience layer over those compilations rather than an authority in its own right.

Raw ADS-B and datalink collection produces hex addresses and callsigns, which are machine identifiers with no analytical meaning until they are resolved. This source is the cheapest and fastest way to perform that resolution at scale, with no key, no quota negotiation and no account to attribute your queries to an organisation. Its second function is less obvious and more valuable: it is a fast route from callsign to a pair of airports, which converts a bare identifier into a geographic hypothesis you can test. For high-volume triage – deciding which of ten thousand tracked aircraft in a region deserve an analyst's attention – a keyless resolver that returns type, operator and probable route in one call is worth more than a slower, more authoritative service, because triage is about ranking rather than proving. The correct mental model is a first-pass lookup that generates hypotheses, backed by a registry check for anything that will appear in a finished product.

Who publishes it, and why that matters

The project is maintained by a single independent developer and published as open source, which is both its strength and its risk. The strength is transparency: the code is readable, the data pipeline is visible, and there is no commercial incentive shaping what is returned or hidden. The risk is bus factor. A free, unauthenticated public API run by one person has no funding model, no support obligation and no continuity plan, and services in this category do disappear or move behind rate limits when they become popular. There is no charge, which means there is also no relationship: you have no standing to ask for uptime, and the polite behaviour is to cache heavily and query as little as you can. For any workflow that would break if this endpoint vanished, either self-host from the published source or maintain a second resolver, and treat the free service as an accelerator rather than as infrastructure.

Provenance is the first question to ask of any dataset and the one most often skipped. Who collects it, what their incentive is, whether they publish a methodology, and whether they correct the record when they get something wrong all bear directly on how much weight a finding drawn from it can carry.

What a record actually contains

The fields you will be working with, what each one means, and whether it is something you can pivot on. Read the meanings carefully — more analysis is wrecked by misreading a field than by failing to find one, and a field that looks like an observation is often an inference.

Field	Type	What it means	Pivot value
`mode_s`	string	The 24-bit ICAO transponder address in hex, and the primary key for aircraft lookups. It is allocated by the state of registry and changes if the airframe is re-registered abroad.	ADS-B tracks, datalink messages, national registry, country allocation block.
`registration`	string	The civil registration mark. Formatting conventions differ by country and the same physical airframe carries different marks across its life.	National registry, ownership records, maintenance and incident history, aircraft photography.
`type`	string	Plain-language aircraft type and variant. Useful for human reading and for judging plausibility of a track, but not a controlled vocabulary.	Performance envelope, role inference, fleet analysis.
`icao_type`	string	The ICAO type designator, a short controlled code. This is the field to join on when combining fleet data across sources, because plain-language type strings vary.	ICAO aircraft type documentation, performance categories, flight plan data.
`manufacturer`	string	Airframe manufacturer as recorded in the compiled dataset. Reflects the original manufacturer rather than any subsequent corporate reorganisation of the brand.	Export control classification, fleet and supply chain analysis.
`registered_owner`	string	The name recorded against the registration in the underlying dataset. For a large share of business aviation this is a trust, a bank, a leasing company or a special purpose vehicle rather than the party using the aircraft.	Corporate registry, beneficial ownership research, sanctions screening – and this pivot is where most of the analytical work actually is.
`registered_owner_country_name`	string	Country associated with the registration. It tells you the flag, not the operator's home, not where the aircraft is based and not who controls it.	Registry jurisdiction analysis, flag-of-convenience patterns in aviation.
`registered_owner_operator_flag_code`	string	A short code used in the ADS-B community to select an operator livery or flag image. It is a display convention, not an authoritative operator identifier.	Operator identity as a hypothesis only; verify against schedule or registry data.
`url_photo`	string	A link to aircraft photography for the registration, sourced from a spotting community. Photographs are of the registration at some past time, not necessarily of the current airframe or configuration.	Visual confirmation of type and livery; date the photograph before relying on it.
`callsign`	string	The flight identifier submitted in a route lookup, with ICAO and IATA variants returned separately because they are different strings for the same commercial flight.	Schedule data, operator identification, route hypothesis.
`origin`	array	Origin airport object with ICAO and IATA codes, name, municipality, country, elevation and coordinates. It is the airport normally associated with the callsign, not an observed departure.	Geospatial analysis, airport entity, corroboration against an actual track.
`midpoint`	array	An intermediate stop where the route has one. Its absence does not prove a non-stop flight – it proves the compiled dataset recorded no stop.	Multi-sector route analysis; technical stop detection when combined with track data.
`destination`	array	Destination airport object in the same shape as origin. Subject to the same caution: this is the scheduled endpoint, not where the aircraft landed.	Arrival hypothesis for track correlation; diversion detection when track and route disagree.
`airline`	array	Airline object with name, ICAO and IATA codes, country and radio callsign. Derived from the callsign prefix, so it identifies the code holder rather than the aircraft's operator on the day.	Operator entity, codeshare and wet-lease analysis, corporate ownership of the carrier.

Coverage — and what is not in it

Coverage is best understood as inherited. The aircraft data derives from the open compilations maintained by the ADS-B community, which are strongest for commercial airline fleets worldwide, good for business aviation in jurisdictions with open registries, weaker for general aviation, and thin for military and state aircraft outside those that fly in the civil system with published registrations. Route data covers scheduled commercial services with recognisable callsigns and covers them reasonably well; it does not meaningfully cover charter, cargo tramp operations, ferry and positioning flights, general aviation, business jets or military movements, because those do not have stable published routes to compile. Airport data has broad global coverage including small fields, drawn from open airport datasets. Update rhythm is periodic rather than continuous: the underlying compilations are refreshed on their own schedules and the API reflects them, so a newly registered aircraft or a recently changed owner may take weeks to appear. There is no historical dimension at all – you get the current record, with no prior registrations, no ownership history and no indication of when the record last changed.

Known blind spots

Absence of evidence here is not evidence of absence. These are the conditions under which adsbdb will not show you something that is nevertheless real:

There is no ownership history. A record shows the current registered owner in the compiled dataset, so an aircraft sold last month may still resolve to its previous owner and there is nothing in the response to warn you.
Registered owner is frequently a trust, bank or leasing vehicle, particularly for US-registered business aircraft, which means the field answers a legal question rather than the operational question of who uses the aircraft.
Route lookups only work for callsigns that correspond to scheduled services; charters, ferry flights, positioning legs, cargo tramp operations and business aviation return nothing, and these are disproportionately the flights an investigation cares about.
Aircraft using a privacy or temporary ICAO address will not resolve, and the failure is silent – you get no result rather than an indication that the address is a privacy allocation.
Military and state aircraft are poorly represented, and where they do appear the owner and operator strings are often generic or outdated.
New registrations, re-registrations and de-registrations lag by an unpredictable interval, so the source is systematically weakest at exactly the moment an airframe changes hands – which is when asset-tracing work needs it most.
There is no confidence indication or provenance on any field, so a correct record and a stale record are visually identical and cannot be distinguished without an external check.
Airports appear with their compiled coordinates and codes but the dataset does not record operational status, so closed, seasonal and military-restricted fields resolve as normally as active international airports.
The service carries no coverage statement of its own, so you cannot tell whether an empty result means the aircraft does not exist, is not in the compilation, or is deliberately unlisted.

Write the blind spot into the product. A statement that something “was not observed in adsbdb” is defensible; a statement that it “did not happen” is not, and the difference is what survives cross-examination.

Access, licensing and what you may do with it

Access model: Open — no account required

Access is as simple as it gets: an HTTPS GET against the public API host with the identifier in the path, no key, no account, no signup. The three lookup families are aircraft by Mode S hex or registration, flight route by callsign, and airline by code, and the project's repository documents the exact paths and response shapes – read it rather than guessing, because the response nests objects and a naive parser will silently produce nulls. There is a health endpoint for checking that the service is up, which is worth wiring into your pipeline so that a resolver outage is reported rather than appearing as a wave of unresolved aircraft. For a serious deployment, the more robust option is to self-host: the source is published, the data is open, and running your own instance removes both the rate limit and the dependency on someone else's goodwill. Doing that also lets you record which snapshot of the underlying data you resolved against, which is the piece of provenance the public service cannot give you.

Licence

The software is open source under the licence stated in its repository. The data is a different question and a genuinely unclear one: it is compiled from community aircraft and airport datasets which themselves carry a mixture of open, public-domain and unstated terms, and photography links point to a third-party spotting community with its own copyright position. In practice this means internal analytical use is uncontroversial, redistribution of the underlying compilation is not something to assume, and republishing aircraft photographs requires attention to the photographer's rights rather than to this API's terms. Do not embed photo URLs in a published product without checking the source site's position. If you intend to build a commercial product on the resolved data, resolve the provenance chain back to the original compilations and satisfy yourself about each one, or use an authoritative registry with clear terms instead.

Rate limits and fair use

The project applies an IP-based rate limit and documents it in its repository; treat that as a modest allowance intended for interactive and light automated use rather than for bulk resolution. The practical discipline is caching. Aircraft records change on a timescale of months, so a local cache with a multi-week expiry will absorb the overwhelming majority of your lookups and reduce your query volume by an order of magnitude. Route lookups change with the schedule season and can be cached similarly. If you find yourself needing sustained high-rate resolution, that is the signal to self-host rather than to distribute your requests across addresses. Identify yourself with a descriptive user agent so that the maintainer can contact you rather than simply block you if your traffic becomes a problem.

Licensing changes, and it changes without warning. A dataset that was free for research this year may not be free for commercial or evidential use next year. Confirm the current terms before you build a dependency on it, and record the terms you relied on alongside the data — the licence in force at the time of collection is part of the provenance.

Collecting it

How adsbdb is actually pulled, in the order you would set it up. Prefer the bulk or export interface over per-item lookups wherever one exists: it is kinder to the publisher, faster for you, and gives a reproducible snapshot rather than a series of point-in-time answers you cannot reconstruct later.

Method	Format	Cadence	Notes
Aircraft lookup by hex	JSON	on demand; cache for weeks	The primary use. Resolve every distinct 24-bit address once, store the result with the resolution date, and re-resolve on a slow cycle rather than per observation.
Aircraft lookup by registration	JSON	on demand	The reverse direction, useful when your starting point is a registry record, a photograph or a document rather than a transponder observation.
Callsign route lookup	JSON	on demand; cache per schedule season	Generates a route hypothesis for scheduled traffic. Never store the result as an observed flight; store it as an expectation to be tested against a track.
Airline lookup	JSON	rare; cache indefinitely and refresh quarterly	Resolves carrier codes to named entities. Small, stable and worth mirroring locally in full rather than querying.
Self-hosted instance	bulk	rebuild when upstream data updates	Run the published service against your own copy of the underlying data. Removes the rate limit, removes the dependency, and lets you record exactly which data snapshot a resolution came from.

Ingesting it into the platform

Every step below is idempotent and cursor-based: interrupt one and it resumes from where it stopped rather than duplicating rows or losing progress. Collection is recorded per source, so a feed that quietly stops publishing shows up as a stale timestamp instead of silently thinning your coverage.

Register as an enrichment source — Add adsbdb in sources.php as a resolver rather than a feed, so it is clear in the catalogue that this source enriches observations from elsewhere and produces no observations of its own.
Build a resolution cache — Store every lookup result keyed on the identifier with the resolution timestamp, and have enrich.php consult the cache before the network. This is the single change that makes the source usable at scale.
Resolve aircraft identity — Run resolve-everything.php across distinct hex addresses from your ADS-B and datalink collection, writing type, operator and registered owner as attributes of the aircraft entity rather than overwriting anything the observation asserted.
Attach route hypotheses — For scheduled callsigns, attach the returned origin and destination as an expected route flagged as a hypothesis, so that later correlation against actual tracks can confirm or contradict it explicitly.
Cross-check against the second resolver — Run the same identifiers through the alternate aircraft database and record disagreement as a data quality flag on the entity, which is what tells an analyst when a registry check is required.
Escalate to authoritative sources — Where a resolved owner will appear in a product, route the registration to a national registry check and to sanctions and corporate screening rather than publishing the compiled owner string.
Expose in entity views — Surface the resolved attributes on the aircraft entity so that explore.php, pivot.php and link-analysis.php can move from an aircraft to its owner, operator and airports without re-querying.
Age and refresh — Re-resolve cached records on a rolling schedule and record changes as events on the entity, because a change in registered owner is itself an intelligence observation rather than a cache update.

Registered sources and their last-collected state are listed in sources.php, and the scheduled chain that keeps them current is in automation.php.

How it is wrong, and how to tell

Every dataset is wrong in characteristic ways. Knowing which ways is the difference between using a source and being used by one, and it is the part of source evaluation most often skipped because it is the part that takes work.

Judge this source by what it is: a convenience layer over community compilations, with no independent verification and no confidence metadata. For mainstream commercial fleets it is accurate and useful, because the underlying compilations are actively maintained by people who care about airline fleets and errors are noticed. For business aviation it is adequate on type and registration and unreliable on ownership, because ownership in that sector is deliberately layered and the compiled owner string is a legal formality. For military, state and general aviation it is thin. Route data is the weakest component and should be treated as a scheduling expectation rather than data. The honest summary is that it is right often enough to be extremely useful for triage and wrong often enough to be dangerous in a finished product. The basis for judging any particular record is not the record itself – it carries no provenance – but whether an independent source agrees. Build that check into the workflow for anything consequential, and accept the compiled answer for everything else.

Characteristic false positives

A stale owner is the characteristic error. The aircraft was sold, the compilation has not caught up, and the API returns the previous owner with exactly the same confidence as a current one, which in a sanctions or due diligence context produces a materially false finding.
The registered owner for US business aircraft is very often a trust or bank acting as owner trustee, and reading that name as the party operating or benefiting from the aircraft is a systematic misattribution rather than an occasional one.
Route lookups return the schedule, so a diverted, cancelled or repositioned flight resolves to a destination the aircraft never approached, and the response gives no indication that it is describing a plan rather than an event.
Callsigns are reused daily and across carriers, so a route returned for a callsign is only correct if the callsign was used by the expected operator on that day, which the lookup cannot check.
Re-registration breaks the hex-to-registration link, and the compilation may carry either the old or the new pairing for a period, meaning a track can be attributed to an airframe that no longer holds that address.
Photographs are of a registration rather than of the airframe in its current state; a mark reissued to a different aircraft or an aircraft repainted for a new operator produces a picture that misleads a reader more effectively than a wrong text field.
The operator flag code is a display convention borrowed from map software and is neither authoritative nor stable, so building operator attribution on it produces errors that are hard to trace afterwards.
An empty response is ambiguous by construction – unknown aircraft, privacy address, or gap in the compilation are indistinguishable – and treating a null as evidence of anything is unsupported.

None of these make the source unusable. They make it a source that requires corroboration before an assertion built on it goes into a product, which is true of every source and admitted by few.

Ageing

Ageing is the defining weakness. There is no last-updated field on a record, so a resolution captured today may reflect a compilation snapshot that is months old, and you cannot tell. Aircraft type and manufacturer effectively never go stale. Registration and hex pairing go stale on re-registration, which for an active business jet or a leased airliner can be a yearly event. Registered owner goes stale fastest and matters most: ownership transfers are exactly what asset-tracing work is trying to detect, and this is the field the compilation is slowest to reflect. Route data goes stale each schedule season, and an out-of-season route looks identical to a current one. A stale record therefore looks completely normal, which is why the operational answer is procedural rather than technical: stamp every resolution with the date it was performed, re-resolve on a schedule, treat a change in the returned owner as an event worth an analyst's attention, and never let a compiled owner string reach a finished product without a registry check performed on a known date.

What this source feeds

A source is only worth what it lets you conclude. These are the disciplines that collect through it, the mission domains it serves and the data points it yields — every one is a tag, so you can follow any thread from here into the rest of the library.

Collected by these intelligence disciplines

Aviation Intelligence

Serves these mission domains

Aviation Security

Yields these data points

How each sector uses adsbdb

The same dataset is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The records are shared — the constraints, thresholds and outputs are not.

🎖 Military and defence

Used mainly as a triage accelerator over a broad air picture: resolving thousands of observed addresses into types and operators quickly enough to identify the handful worth looking at. It is good at recognising commercial and contracted transport types and poor at anything military-registered, so its role is to clear the civil clutter rather than to identify military assets. For logistics analysis, the type and operator resolution is genuinely useful when combined with track data, since contracted cargo and charter operators appear in the compilation. Do not rely on it to characterise a state aircraft; those need registry and open reporting work.

🕵 National intelligence

The standard first-pass resolver in AVINT workflows, valuable because it is fast, keyless and does not create an account trail linking your organisation to the aircraft you resolve. That last property is not trivial – resolving a target airframe through an authenticated commercial service tells that service what you are interested in. Analytically, the source's job ends at hypothesis generation: it tells you the airframe is a particular type with a particular nominal owner, and every subsequent step – beneficial ownership, operator on the day, sanctions exposure – belongs to registry, corporate and sanctions sources. Treating the compiled owner as an ownership finding is the most common failure of this workflow.

👮 Law enforcement

Useful for rapid identification during live operations and for building the aircraft entity in an investigation file. The registration and type are usually reliable enough to act on for identification purposes. The owner field is not evidence and should never be presented as such; obtain the registry record through proper channels for anything that will be relied on. Route lookups can support an initial timeline but must be replaced by actual flight records obtained from the operator or the air navigation service provider before they carry weight. As with any unauthenticated free service, document what you queried and when, because the answer may differ if the question is asked again later.

🔍 Private investigation and corporate security

The everyday tool for aircraft-related enquiries: turn a tail number seen on a ramp or in a photograph into a type and a nominal owner in seconds, then decide whether the matter justifies a registry search. Its central limitation is exactly the thing private clients most often want to know, namely who really controls the aircraft, and the answer here is a trustee or a leasing company by design. Treat the returned owner as the start of a corporate-structure enquiry rather than as its conclusion. Keep in mind that a stale owner presented to a client as current is a professional risk, so date every lookup in the file.

📰 Journalism and OSINT media

Fast, free and unattributed resolution suits newsroom workflows, particularly for verifying what type of aircraft appears in a photograph or what a callsign in a leaked document refers to. For publication, the standard should be higher: verify the registration against the national registry, verify the owner independently, and be explicit that ownership records for aircraft are frequently held by trusts and leasing structures that do not indicate use. Avoid republishing linked photographs without addressing the photographer's rights. The route lookup is a useful reporting shortcut and a poor factual claim; say a flight was scheduled to go somewhere, not that it went.

🌍 NGO, humanitarian and human rights

For documentation of arms transfers, sanctions circumvention and suspect flight activity, this provides the quick identification step that makes a large set of observed aircraft tractable. The compiled owner string is often the first visible thread in a chain that leads to a leasing company in one jurisdiction and an operator in another, and that thread is genuinely useful even though it is not the answer. The obligation in advocacy documentation is to be explicit about the limits: state that ownership data is compiled from open sources of uncertain currency, state the date of lookup, and corroborate with registry records before naming a company in a public report.

🎓 University and research

A practical enrichment layer for air transport, security and economic geography research working with ADS-B datasets, and a good teaching example of how identifier resolution works and where it fails. For quantitative work the absence of provenance and versioning is a real methodological problem: results are not reproducible unless you record the resolution date and ideally self-host against a pinned data snapshot. Researchers studying ownership structures should treat the registered owner field as a variable measuring the legal registrant, which is a legitimate object of study in its own right, rather than as a noisy proxy for control.

Playbook: working adsbdb end to end

A repeatable sequence from first pull to finished product. Each phase states what you are trying to establish, not merely what to click — the objective is a defensible chain of reasoning, not a completed checklist.

Phase 1 — Decide what the resolution is for

Separate triage from attribution at the outset. If you are ranking thousands of observations to find the interesting ones, this source is ideal and its error rate is tolerable. If a name will appear in a product, this source is a starting point and a registry is the destination. Deciding which mode you are in prevents the most expensive mistake with this source.

Phase 2 — Normalise identifiers before querying

Trim callsign padding, lowercase hex addresses, and canonicalise registration formats, which vary by country in ways that break naive matching. A surprising share of empty responses are formatting failures rather than genuine absences, and the difference matters because one is a data gap and the other is your bug.

Phase 3 — Build the cache before the workflow

Stand up local caching as the first component, not as an optimisation later. Aircraft records change monthly at most, so caching converts an unusable volume of queries into a trivial one and makes the whole approach sustainable against a free volunteer service.

Phase 4 — Stamp every resolution with a date

Record when each lookup was performed and store it with the result. Because the API carries no last-updated field, your own resolution date is the only temporal information you will ever have about the record, and without it your data has no way to age.

Phase 5 — Read the owner field as a legal fact

Interpret registered owner as the entity holding the registration, which in business aviation is routinely a trust, a bank or a special purpose company. Record it as such. Then treat identifying the operator and the beneficiary as a separate task using corporate registries, sanctions data and operational evidence.

Phase 6 — Test route hypotheses against tracks

Take the origin and destination returned for a callsign and check them against the actual ADS-B track for that flight. Agreement is a small confirmation. Disagreement is often the most interesting thing in the case, because it means a diversion, a substitution or a callsign that was not used as expected.

Phase 7 — Run a second resolver deliberately

Resolve consequential identifiers through the alternate aircraft database as well and compare. The two compilations share ancestry but diverge, and the divergence is a free quality signal: agreement raises confidence cheaply, disagreement tells you exactly which records need registry work.

Phase 8 — Escalate to the registry for anything consequential

For any aircraft that will appear in a report, be named in an allegation, or be the subject of an action, go to the national civil aviation registry. Record the registry, the date, and the exact record retrieved. Compiled data does not survive challenge and registry data usually does.

Phase 9 — Screen the resolved entities

Push registered owner, operator and airline names through sanctions, PEP and corporate screening. This is where an aviation observation becomes a compliance or enforcement finding, and it is a step that costs little and is skipped surprisingly often.

Phase 10 — Watch for change rather than state

Re-resolve your watched airframes on a schedule and diff the results. A change in registration, hex address or registered owner is an event: it can indicate a sale, a re-flagging, or a deliberate restructuring ahead of scrutiny. Detecting the change is more valuable than knowing the current state.

Phase 11 — Handle the empty response honestly

When a lookup returns nothing, classify why: malformed identifier, privacy address allocation, genuinely obscure aircraft, or gap in the compilation. Each has a different follow-up. Recording all four as unknown loses information, and treating any of them as evidence that the aircraft does not exist is unsupportable.

Phase 12 — Plan for the service disappearing

Before you depend on it, decide what happens if it stops. Self-host from the published source, mirror the airline and airport tables locally, and make sure your resolution cache is durable enough to keep the case usable. A free single-maintainer API is a fine accelerator and a poor foundation.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

What to pair it with

No single source carries a finding. These are the datasets that corroborate, extend or contradict this one — and a source that contradicts is worth more than one that agrees, because it is the only thing that will tell you when you are wrong.

Source	Relationship	What it adds
hexdb.io	corroborates	The nearest equivalent free resolver, built on overlapping but not identical data. Running both and comparing is the cheapest quality control available for aircraft identity.
OpenSky Network	prerequisite	Supplies the hex addresses and callsigns that this source resolves. The resolver has no value without an observation stream feeding it.
Airframes.io	extends	Provides registrations and flight identifiers from datalink messages, including for aircraft outside ADS-B coverage, which this source can then resolve.
National civil aviation registries	supersedes	The authoritative record of registration, type and registered owner. Where a registry answer exists, it replaces rather than supplements the compiled answer.
OpenSanctions	extends	Screens resolved owners, operators and carriers against sanctions, PEP and watchlist data, which is the step that turns identification into a compliance finding.
OurAirports	corroborates	Open airport dataset covering the fields returned in route lookups, useful for validating airport codes and coordinates and for adding operational context.
Planespotters	extends	The photography community behind the image links; its per-airframe pages often carry fleet history that the API does not expose.

Legal, ethical and operational constraints

The immediate constraints are light and the downstream ones are not. Querying a free public API for aircraft identifiers raises no meaningful legal issue in itself. What follows does. Attributing an aircraft to a named company or individual on the strength of a compiled ownership record carries defamation exposure if the record is stale, and stale ownership records are this source's characteristic failure. In most data-protection regimes, an aircraft registration linked to an identifiable private owner is personal data, so compiling and retaining ownership and movement profiles requires a lawful basis and a retention limit even though each individual lookup is trivial. Where the analysis feeds sanctions or export-control decisions, the standard of evidence is set by the regime rather than by convenience, and compiled community data will not meet it. Photography links carry third-party copyright. The professional rule is simple: use this source freely for internal analysis, and never let one of its fields be the sole basis for naming a party in anything that leaves your organisation.

Operational security

The absence of authentication is a genuine operational advantage: your lookups are not tied to an account and there is no commercial relationship in which your interests are recorded and potentially disclosed. That advantage is not complete. The service sees your source address, timing and the exact identifiers you request, and a burst of lookups against a single unusual airframe is legible in a log. If your interest in a specific aircraft is sensitive, resolve it alongside a broader set rather than alone, route through infrastructure not attributable to your organisation, and prefer a cached or self-hosted resolution so that the query never leaves your network at all. Self-hosting is the strongest answer here and is unusually practical because the code and data are open. Consider also the downstream exposure: if your resolution results are shared into a partner system or a published product, the pattern of which airframes you resolved is itself an indication of your collection priorities.

Two rules that hold regardless of jurisdiction. Collection that is lawful is not automatically proportionate, and a dataset assembled for one purpose does not carry consent for another. Where the records concern identifiable people, the question is not only whether you may hold the data but whether holding it serves the purpose you are accountable for.

Is it earning its place?

Sources accumulate. Feeds get added during an incident and are never reviewed again, and a decade later the pipeline is carrying dead weight that nobody dares remove. These are the measures that show whether adsbdb is contributing anything, and they are worth baselining now so the answer is available later.

Cache hit rate on aircraft lookups, which should climb well above ninety per cent in steady state; a low rate means your identifier normalisation is failing rather than that your targets are diverse.
Resolution success rate by aircraft class, tracked separately for airline, business, general and state aviation, because a single overall figure hides exactly the gaps that matter.
Disagreement rate against the second resolver, which is your best available proxy for the error rate of a source that publishes no confidence data.
Proportion of consequential findings where a registry check confirmed the compiled owner, tracked over time as a direct measure of how far this source can be trusted in your domain.
Median age of cached resolutions in active cases, to catch the situation where a long-running investigation is quietly reasoning from months-old ownership data.
Number of ownership changes detected by scheduled re-resolution, which measures whether you are using the source as a change detector rather than only as a lookup.
Rate at which route hypotheses were contradicted by observed tracks, which is both a data quality measure and, in some contexts, an operational signal worth its own attention.

Beware of volume. Indicator counts rise easily and say almost nothing. Unique contribution — findings this source produced that no other source in your stack would have — is the measure that matters, and it is usually far lower than anyone expects.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

Resolution is not attribution. This source tells you which airframe an identifier refers to; it does not tell you who controls it, who operates it or who was aboard, and the gap between those statements is where most aviation analysis goes wrong.
A trustee is not an owner in the sense you mean. Large parts of the business aviation fleet are registered to owner trustees for regulatory reasons, and reporting the trustee as the owner is a systematic error that a careful reader will catch immediately.
Cache and date everything. Because the API exposes no record timestamp, your own resolution date is the only temporal metadata that will ever exist, and an undated resolution is unusable in a case that runs for months.
Route data is a schedule, not a flight. Treat origin and destination as a testable expectation and let the actual track adjudicate; the cases where they disagree are usually the reason you were looking.
Two resolvers cost nothing and buy a real quality signal. Where the free databases agree, confidence is cheap; where they disagree, you have identified precisely which records deserve registry work.
An empty response has four different meanings and none of them is that the aircraft does not exist. Classify the null rather than absorbing it, because a privacy address returning nothing is itself a significant finding.
Watch for change, not just state. Scheduled re-resolution turns a static lookup service into a detector for sales, re-registrations and re-flagging, which is often what the investigation is actually about.
Self-host when it matters. The code and data are open, and running your own instance gives you throughput, independence, query privacy and a pinned data snapshot you can cite – four problems solved by one decision.
Never let a compiled field be the sole basis for naming a party. The rule is not about this source's quality; it is about the fact that no compiled dataset carries the provenance a named allegation requires.

Questions analysts actually ask

Why does my aircraft lookup return nothing?

Four common reasons: the identifier is malformed or padded, the address is a privacy or temporary allocation that has no registry counterpart, the aircraft is genuinely absent from the community compilation, or it is a class of aircraft the compilation covers poorly. Check formatting first, then consider a privacy allocation, then try the alternate resolver.

Is the registered owner the person who uses the aircraft?

Often not. In several major registries, particularly the United States, aircraft are held by owner trustees, banks or leasing vehicles for legitimate regulatory reasons. The field answers who holds the registration. Identifying the operator and the beneficial user is a separate corporate-research task.

How current is the data?

Unknown, by construction. The API returns no last-updated field and the underlying compilations refresh on their own schedules. Assume weeks to months of lag on ownership changes, stamp your own resolution date, and re-resolve anything that matters.

Can I use the route lookup to say where a flight went?

No. It returns the route normally associated with the callsign, which is a schedule. Diversions, cancellations, substitutions and repositioning flights all produce a correct-looking route that did not happen. Say the flight was scheduled between two airports, and use the track to say where it actually went.

Should I use this or hexdb.io?

Both. They share ancestry in the same open compilations but diverge in coverage and update timing, so running both and comparing gives you a quality signal that neither provides alone. Where they agree, proceed; where they disagree, go to the registry.

Is it acceptable to bulk-resolve a large fleet?

Not against the public service. It is free, single-maintainer infrastructure and a bulk job is a real cost to someone. Cache aggressively, and if you genuinely need volume, self-host from the published source, which is both more polite and better for you because it removes the rate limit and gives you a pinned snapshot.

Can I publish the aircraft photographs it links to?

Not without addressing the photographer's rights. The links point to a spotting community where images are copyright of individual photographers. The API's terms do not grant you anything in respect of those images, and republishing them in a report or article needs its own permission.

Does it cover military aircraft?

Barely, and unevenly. Aircraft that operate in the civil system with published registrations may appear; genuinely military-registered airframes generally do not, and where they do the details are often generic or dated. Use dedicated military aviation research and registry sources for that work.

What happens to my analysis if the service shuts down?

That is the right question to ask before depending on it. Mitigate by caching durably, mirroring the small airline and airport tables locally, and self-hosting the service from its published source. A free API run by one person should be an accelerator in your architecture, never a load-bearing component.

Standards, formats and interoperability

What this source speaks natively, and what it has to be translated into before a partner can consume it. Work that arrives in a recognised format is easier to defend, easier to hand over and easier to automate against:

ICAO 24-bit aircraft addresses are allocated in national blocks under ICAO Annex 10, which is why the address itself carries a state-of-registry signal independent of any database lookup.
ICAO aircraft type designators provide the controlled vocabulary that makes fleet analysis join correctly across sources, unlike free-text type strings.
ICAO four-letter and IATA three-letter location indicators identify airports, and route responses return both because different upstream systems use different ones.
ICAO three-letter and IATA two-letter airline designators, together with the radio telephony callsign, are the three identifiers a carrier is known by and they must be reconciled explicitly.
National civil aviation registries are the authoritative source for registration and ownership, and every compiled database in this space is downstream of them.
Open airport datasets provide the coordinate and code reference behind route responses, and inherit the coverage and currency of those projects.
The platform exports resolved aircraft, operator and airport entities in STIX 2.1, MISP, CSV, JSON and JSONL for onward analysis.

References

Primary documentation and authoritative references for this source. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

adsbdb — adsbdb. The service homepage, with the current description of what the API returns and how to call it.
adsbdb source code — mrjackwills. The authoritative documentation of endpoints, response shapes and rate limiting, and the starting point for self-hosting.
hexdb.io — hexdb.io. The alternate free resolver. Worth reading alongside this one to understand where the two compilations diverge.
Planespotters — Planespotters.net. Source of the linked aircraft photography and a useful per-airframe fleet history reference in its own right.
OurAirports — OurAirports. Open airport data underlying the codes and coordinates in route responses, with clearer provenance than most alternatives.
Mictronics — Mictronics. Maintainer of community aircraft database work that the ADS-B ecosystem depends on, and useful background on how these compilations are built.
International Civil Aviation Organization — ICAO. The standards body behind aircraft addressing, type designators and location indicators used throughout the responses.
Federal Aviation Administration — FAA. Operator of the largest civil registry and the regulator whose trust-ownership rules explain why registered owner is so often a bank.
OpenSanctions — OpenSanctions. Screening data for the owners, operators and carriers this source resolves, and the natural next step after identification.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this source: it caches and dates every resolution, runs a second resolver in parallel to flag disagreement, and escalates any aircraft that will appear in a product to an authoritative registry check.. Browse the full source catalogue, or follow any tag above into the rest of the library.