Introduction
What FlightByte does, the two requests most integrations are made of, and where to go next.
FlightByte is a flight status API built for the code on the receiving end. You can ask it about a flight, and you can ask it to watch one: from then on every gate change, delay, departure, landing and baggage carousel arrives at your endpoint as a signed webhook, while FlightByte does the polling on a schedule that tightens as departure nears.
The shape of it
Everything lives under one base URL and one header.
https://api.flightbyte.dev/v1
x-api-key: <your key>A typical integration is two requests.
curl "https://api.flightbyte.dev/v1/flights/TK/1848/2026-09-12" \
-H "x-api-key: $FLIGHTBYTE_KEY"curl -X POST "https://api.flightbyte.dev/v1/subscriptions" \
-H "x-api-key: $FLIGHTBYTE_KEY" \
-H "content-type: application/json" \
-d '{
"carrier": "TK",
"flightNumber": "1848",
"date": "2026-09-12",
"webhookUrl": "https://yourapp.com/hooks/flights"
}'From here on, FlightByte polls the flight, diffs every answer against the last one, and sends you only what changed, signed with the subscription's secret. When the flight has arrived and the baggage belt is known, the watch ends on its own.
What you get back
Every flight is returned as one canonical snapshot, whichever upstream it came from: scheduled, estimated and actual times in UTC and local time, terminals, gates, baggage carousel, status with a coarse phase, aircraft, codeshares, every leg the flight number operates that day, and the airline's own timeline of changes. The same snapshot travels inside every webhook, next to the list of what changed.
Where to go next
Quickstart
From a key to your first webhook in ten minutes.
Flights
Lookups, leg selection, timelines and caching.
Subscriptions
Watching a flight, its lifecycle, and the delivery log.
Webhooks
Payloads, the 23 change types, signatures and retries.
API reference
Every endpoint with schemas, examples and a live playground.
Errors
The error envelope and what each status code means.