Reach and limits
What it answers, and where it stops.
Coverage is the network a lookup can reach. How we produce the record is sealed — you get the answer, not the machinery.
1,240
Carriers
9,800
Airports
10 yrs
History
Sealed
Resolver
What is queryable
These describe the network a lookup can reach, not the number of rows we happen to have frozen already.
1,240
Addressed by IATA designator. You never load a carrier table — the number in the query is the key.
9,800
Origin and destination come back as IATA codes on the resolved record, whether or not you supplied them.
10 yrs
Departures and arrivals reaching back roughly a decade. Anything settled inside that window is a query, not a data request.
A flight is answerable long before we have ever cached it, so coverage is a statement about what you can ask for. What we keep afterwards is a much narrower set — see what we store.
What a lookup costs
We publish no SLA number. The response already carries the measured wall clock.
meta.durationMs is the wall clock for the whole resolve. A settled record replayed from storage reports 0.
Passing origin disambiguates a number that flew more than once that day. It is the one input you control that changes whether a stubborn lookup settles.
What we store
Storage is narrow on purpose: only the records that cannot change again.
All four must hold. Fail any one and nothing is written — the lookup simply runs again next time.
Unique on (flightNumber, flightDate), so a re-resolve updates in place. The row holds the selected record and the delay block, and is replayed verbatim as a normal response with meta.cached: true.
Proof images are stripped before anything reaches storage — the key survives, the image bytes do not.
Limits, stated plainly
The things worth knowing before you build against it.
A flight that was fine returns nothing to settle
Only a delay, cancellation or diversion becomes a record. A flight that operated normally comes back as selected: null.
On-time and not-found are never stored
Only settled disruptions are persistable, so asking repeatedly about flights that were fine always costs a live resolve — and one request each time.
A stored record is keyed on number and date
Origin and destination narrow a live resolve, but the frozen record is unique on flight number and UTC date. A re-resolve updates that row in place rather than accumulating duplicates.
Recent flights stay live
Anything inside three UTC days is resolved again on every request, because a status that recent can still change underneath you.
No terminal, gate or baggage data
The record covers scheduled, estimated and actual times on both ends, delay, airline and aircraft. Terminals, gates, belts and seat maps are not part of it.
Every timestamp is UTC
Flight dates, block times and the three-day settle arithmetic are all UTC. There is no local-time rendering anywhere in the payload.
Check it against a flight you know.
The console replays a settled record exactly as the endpoint returns it.