TK1848 is not a flight. It is the name of a route in an airline's timetable, flown by a different aircraft every day, and it will be flown tomorrow too. Worse, some numbers are flown more than once on the same day: TK1 is Istanbul Sabiha Gökçen to Amsterdam in the morning and Istanbul Airport to New York in the afternoon, two aircraft, two crews, one number.
A flight ID is what identifies one of those: a specific leg, on a specific date, between a specific pair of airports. Every serious flight data source has one; FlightAware calls it fa_flight_id, the airline's operations system has its own, and the passenger never sees any of them.
Why it matters to an integration
Anything keyed on a flight number alone has two failure modes. It watches today's instance when the booking was for tomorrow, or it watches the morning leg when the passenger is on the afternoon one. Both are silent: the status is real, it is just someone else's flight.
In FlightByte
| Identifier | Shape | Use |
|---|---|---|
| Flight number | TK + 1848 | What you look up with, together with the local departure date. |
flightKey | TK1848:2026-09-12, then TK1848:2026-09-12@ATH-IST once the leg is resolved | The canonical key for one leg on one date. Appears in every webhook and subscription. Store it with the booking. |
providerFlightId | An opaque string such as 1407278900, listed under alternates[] | The exact escape hatch: pass it as flightId to pick a leg when airport codes are not enough. |
When a number operates more than one leg on the date, a lookup lists them under alternates and a subscription is refused with a 400 naming them, because watching the wrong aircraft is worse than an error. Pass origin (or destination), which a passenger always knows, and the key gains its @ATH-IST suffix. The full rules are under Flights → Leg selection.