Flight status data is structured information. It describes the changing operational state of a specific flight on a given date. It links the flight and route to scheduled, estimated, and actual times. It also includes events like delays, cancellations, diversions, and gate changes.
Unlike flight schedule data, which lists planned services, flight status data shows how a dated flight changes over time. Online travel agencies (OTAs), travel management companies (TMCs), and other travel platforms can use it.
They can use it to support their monitoring, traveler updates, and disruption workflows.
This guide explains the key fields, how updates work, why time milestones must remain distinct and what enterprise teams need to handle during integration. VariFlight DataWorks supplies the data; customers define their own actions and business rules.
Key Takeaways
- Flight status data combines flight identity, operational times, status changes and airport information.
- Scheduled, estimated, and actual times describe different stages, so you should not use them interchangeably.
- Query APIs retrieve supported records; push services deliver supported updates to monitored flights.
- Field availability, time zones and missing values matter as much as the headline flight status.
What Information Does Flight Status Data Include?
Flight status data combines flight identity, operational milestones and airport context in one dated record. The exact fields vary by flight, source and stage of operation.
| Data group | Example information | What it helps confirm | Example API fields |
|---|---|---|---|
| Flight identity | Flight number and airline | Which flight the record represents | FlightNo, FlightCompany |
| Route identity | Origin and destination airport codes | Which segment is involved | FlightDepcode, FlightArrcode |
| Scheduled baseline | Scheduled departure and arrival | The plan stored with the record | FlightDeptimePlanDate, FlightArrtimePlanDate |
| Expected operation | Estimated departure and arrival | The available expectation | FlightDeptimeReadyDate, FlightArrtimeReadyDate |
| Actual time fields | Recorded actual departure and arrival | The recorded outcome, subject to field definitions | FlightDeptimeDate, FlightArrtimeDate |
| Ground milestones | Off-block and on-block time, when available | Parking-position events, if explicitly defined | FlightIngateTime (arrival-side example) |
| Operational state | Departure, arrival or disruption state | Which state is recorded | FlightState |
| Airport operation | Boarding gate, terminal and baggage carousel | Airport service locations | BoardGate, FlightTerminal, BaggageID |
| Matching context | Codeshare flight number | A marketing/operating relationship to examine | ShareFlightNo |
| Time context | Origin and destination time-zone values | How local timestamps should be interpreted | org_timezone, dst_timezone |
These fields should not be treated as interchangeable. A scheduled time records the plan. An estimated time records a current expectation. An actual time confirms that a specific aircraft milestone occurred.
Some responses also include FFlightDeptimePlanDate and FFlightArrtimePlanDate. Consult the API definition before assigning those fields a versioning or update-history meaning. The scheduled baseline is part of a flight-status record, not a separate timetable product.
How Does Flight Status Data Work?
Flight status data moves through a sequence of identification, collection, normalization and delivery. The customer system then maps each field to its own interface or workflow.
A typical flow is:
- Identify the flight. Match the flight number, flight date, origin and destination.
- Collect source updates. Airlines, airports and other operational sources provide new times, states and service-location details.
- Normalize the record. Standardize identifiers, timestamps, time zones and status values.
- Preserve separate milestones. Keep scheduled, estimated, off-block, takeoff, landing and on-block times in distinct fields.
- Deliver the current record. Return data through an on-demand query or send an update through a push service.
- Apply customer rules. The OTA, TMC or platform decides what to display and which internal action follows.
For example, a customer may query a dated flight before departure and receive scheduled and estimated times. A later supported push update may report a gate change or a new operational state. The customer can retain the original scheduled baseline alongside the update.
The customer owns notification thresholds, retry logic, cache duration and presentation.
How Do Scheduled, Estimated and Actual Flight Times Differ?
Scheduled, estimated and actual times answer different questions. Keeping them separate prevents a changing expectation from overwriting the original plan or a runway event from being presented as a gate event.
| Time type | Question answered | Example use |
|---|---|---|
| Scheduled time | When was the flight planned to depart or arrive? | Original itinerary and comparison baseline |
| Estimated time | When is the flight currently expected to depart or arrive? | Live itinerary before the event occurs |
| Actual off-block time | When did the aircraft leave its parking position? | Start of the ground-departure sequence |
| Actual takeoff time | When did the aircraft become airborne? | Confirmed takeoff milestone, if separately available |
| Actual landing time | When did the aircraft touch down? | Confirmed landing milestone, if separately available |
| Actual on-block time | When did the aircraft reach its arrival stand? | Confirmed stand-arrival milestone, when available |
As an illustrative example, a flight could land at 18:31 and reach its stand at 18:47. Both timestamps can be correct because they describe different events. These are not values from the API excerpt below. Do not assume that FlightDeptimeDate specifically means runway takeoff or that FlightArrtimeDate specifically means touchdown without checking the applicable field definitions.
For a detailed explanation, see Landing Time vs On-Block Time for OTAs.
What Does a Flight Status API Record Look Like?
The following selected fields are reproduced from a VariFlight DataWorks API documentation example supplied for this article. The excerpt illustrates response structure, not an independently verified operational timeline.
{
"FlightNo": "SC7621",
"FlightDepcode": "YNT",
"FlightArrcode": "CAN",
"FlightDeptimePlanDate": "2023-12-22 08:20:00",
"FlightDeptimeReadyDate": "2023-12-22 08:20:00",
"FlightDeptimeDate": "2023-12-22 08:28:00",
"FlightArrtimePlanDate": "2023-12-22 11:20:00",
"FlightArrtimeReadyDate": "2023-12-22 11:20:00",
"FlightArrtimeDate": "2023-12-22 11:28:00",
"FlightIngateTime": "2023-12-22 11:57:00",
"BoardGate": "15",
"BaggageID": "7",
"org_timezone": "28800",
"dst_timezone": "28800"
}The record contains scheduled, estimated and actual time fields alongside flight identity and airport details. The BoardGate and BaggageID values describe airport service locations. Applications should interpret each time field according to its documented definition, rather than infer a runway or gate event from the field name alone.
How Is Flight Status Data Different from Flight Schedule Data?
Flight schedule data describes a planned service. Flight status data describes the current and confirmed operation of a dated flight.
A schedule can state that a flight is planned to depart at 09:00 and arrive at 11:20. The corresponding status record may later show an estimated departure at 09:35, an actual departure field, a changed arrival terminal and an on-block time when those values are available.
The distinction affects system design:
- A booking or itinerary baseline may preserve scheduled times.
- A live flight page needs estimated and actual milestones.
- A disruption workflow needs status changes such as cancellation or diversion.
- A historical record needs the plan and actual outcome stored separately.
VariFlight DataWorks provides scheduled values within supported flight-status records. It does not offer a standalone timetable product. Enterprises that need future planning data should confirm the available status-query window and scope rather than assuming that a flight-status API is a complete schedule database.
How Should Cancellations, Diversions and Returns Be Represented?
Abnormal operations need explicit states because they do not follow the normal departure-to-arrival sequence. A missing arrival time does not by itself prove that a flight was cancelled or diverted.
Customer systems should read the operational state together with the available timestamps and route context:
- Cancellation: the planned flight does not operate as scheduled.
- Diversion: the aircraft lands at an airport different from the planned destination.
- Return: the aircraft returns after departure or during the operating sequence.
- Delay: the flight continues to operate, but one or more milestones move later than the scheduled baseline.
An OTA should not create a normal arrival state for a diverted flight simply because a landing timestamp exists. The landing airport and diversion details must remain associated with the event. A TMC may then use that record as an input to its own duty-of-care workflow.
See How TMCs Can Manage Duty of Care During Flight Diversions for a focused workflow example.
Why Do Codeshare and Operating Flights Matter?
A codeshare allows multiple marketing flight numbers to refer to one operated flight. The traveler may search for the marketing number, while operational milestones originate from the operating service.
Reliable matching therefore needs more than an isolated flight number. A customer should consider:
- Flight date
- Origin and destination
- Marketing flight number
- Operating carrier or operating-flight relationship, when available
- Segment and stop context
- Time zone and overnight-date handling
ShareFlightNo is one example of a codeshare-related field. Its presence alone does not determine which record should appear as the operated flight.
You must read that link using the API documentation and the customer’s matching rules.
If two marketed records refer to the same operated flight, the system may match them inconsistently. This can show different times or statuses. Travelers on the same aircraft may see different information. The customer needs a defined rule for storing, displaying and deduplicating those records.
Codeshare handling is important for cabin and amenity information.
The onboard product depends on the operating carrier and aircraft. Why Cabin Class Alone Is Not Enough covers that topic.
How Should Applications Handle Data Quality, Time Zones and Missing Values?
Flight status records change as information becomes available. Each flight stage does not include values in every field. Airport details, estimated times, and milestones may vary by source and location.
- Missing values: An empty field does not automatically mean cancellation, an unchanged state or a confirmed event. Follow the API’s field definitions and response conventions.
- Time zones: Preserve origin and destination time context when displaying local departures, arrivals and overnight journeys. The sample’s
org_timezoneanddst_timezonevalues are fields to interpret, not substitutes for a documented conversion rule. - Record consistency: Interpret flight identity, date, route and operating state together. One timestamp rarely describes the entire outcome.
These checks belong in the customer’s integration. They help prevent a partial record from appearing as a complete flight timeline.
Who Uses Flight Status Data?
Flight status data supports products that need a current, dated view of an aircraft operation. The same source fields can support different workflows, but each customer controls the final action.
| User | Typical use of the data |
|---|---|
| OTA | Update trip timelines, flight-detail pages and disruption screens |
| TMC | Monitor managed trips and feed duty-of-care workflows |
| Travel app | Build status pages and delay, departure or arrival alerts |
| Airport transfer platform | Adjust the dispatch inputs used for driver and pickup coordination |
| Hotel or resort | Monitor guest arrival flights for transfer and concierge planning |
| Travel insurer | Verify reported delay, cancellation or diversion events |
| Airport commercial team | Relate flight movement changes to staffing or service windows |
| Enterprise developer | Add standard flight records to an internal product or data pipeline. |
For example, an airport transfer platform can use estimated arrival before landing.
It can use actual landing time after touchdown.
It can also use actual on-block time when available. The platform still decides when to contact the driver or traveler. Flight data does not confirm that a passenger has cleared immigration or collected baggage.
See How Flight Status Data Improves Airport Transfer Operations for a detailed implementation scenario.
How Can Enterprises Access Flight Status Data?
Enterprises commonly access current flight records through query APIs or push updates. The correct method depends on whether the application needs information on demand. It may also need to monitor selected flights for changes.
Query API
A query API returns a record.
The customer submits supported identifiers.
These identifiers can include a flight number, date, route, or airport. It suits search, flight-detail pages, support tools and validation workflows.
The customer should cache responses carefully. An old response may contain a valid earlier state but no longer represent the current operation. Cache duration and refresh rules belong to the customer application.
Push Updates
A push service sends changes for monitored flights when supported operational updates occur. It suits alert feeds, disruption monitoring and systems that should not repeatedly request every record.
Push delivery still needs customer-side controls. The receiving system should authenticate the message and identify the flight.
It should handle duplicate or out-of-order updates. It should record the event time. It should retry failed processing based on its own architecture.
Some products use both methods: query to establish the current record, then push updates to maintain it. VariFlight DataWorks supports on-demand queries and push alerts.
These alerts can be proactive for today’s and future flight operations.
This depends on the agreed scope and available data fields.
For request parameters, response fields and delivery details, see the official API documentation index.
What Should Enterprises Evaluate in a Flight Status Data Provider?
A provider evaluation should test field meaning and workflow fit, not just whether an endpoint returns a response. A representative trial should cover normal flights, disruptions, codeshares and missing optional values.
| Evaluation area | Questions to test |
|---|---|
| Coverage and field availability | Are the required flights and fields present in the target markets? |
| Status and time semantics | Are disruptions and scheduled, estimated and actual fields defined clearly? |
| Flight identification | Can dated flights and codeshares be matched for the intended use? |
| Delivery and updates | Do query and push methods fit the customer’s architecture? |
| Documentation | Are parameters, field definitions, examples and errors explained? |
Test coverage against the customer’s actual routes, airports, airlines, and workflow. A single global percentage cannot replace a representative sample.
For a fuller purchasing and integration checklist, see the Flight Status Data API enterprise guide.
How Does VariFlight DataWorks Support Flight Status Data?
The VariFlight DataWorks Flight Status Data API provides structured flight records through standardized JSON access and push updates. The published product scope covers over 97% of commercial flights. It includes data on over 1,200 airlines and 10,000 airports.
Available information can include flight identity and route. It can include scheduled and estimated times. It can include actual movement milestones and operational status.
It can include terminals, gates, and stands. It can include check-in counters and baggage carousels. It can include codeshares and aircraft context.
It can also include airport time zones. Availability varies by field, flight, airport and source.
VariFlight DataWorks is the data layer. It does not sell tickets or provide fares. It does not process PNRs or store passenger identity.
It does not confirm that a traveler completed an airport process. It does not decide which notification, dispatch, claim or service workflow a customer should run. Customers apply their own rules, analytics and business decisions to the supplied data.
Explore the VariFlight DataWorks Flight Status Data API for product scope and trial access. Developers can use the API documentation index for the available query and push specifications.
Frequently Asked Questions
Is flight status data real time?
Flight status data changes as operational information becomes available. Do not interpret “real time” as every field changing at a fixed interval. Update timing varies by event, source, flight stage and field.
Does flight status data include scheduled times?
Yes, a supported flight-status record can include scheduled departure and arrival times as its baseline. VariFlight DataWorks does not offer scheduled timetable data as a standalone product.
Does the estimated arrival time match the actual arrival time?
No. Estimated arrival is the current expectation before the event is confirmed. Actual landing and actual on-block time describe completed aircraft milestones and should remain separate.
Can flight status data confirm where a passenger is?
No. Flight status data describes the aircraft operation. It does not confirm whether a passenger boarded, left the aircraft, cleared immigration or collected baggage.
Does flight status data include codeshare flights?
Flight-status records can include codeshare flight numbers and related context. Customers should test how their routes and use cases match marketed and operating records.
What is the difference between flight status data and ADS-B data?
Flight status data describes operational identity, times, states and airport details. ADS-B data describes aircraft position and movement signals. A platform may combine them, but the datasets answer different questions.
Can you access historical flight status separately?
Yes. Historical flight records support retrospective verification, reliable and comparison of planned and actual milestones. See the VariFlight DataWorks Historical Flight Status Data API.
Related DataWorks Resources
- How Flight Status API Helps Apps Build Reliable Alerts
- Flight Connection and Disruption Management
- Flight Status Data for Airport Transfer Operations
- Flight Disruption Alerts for Travel Management Companies
- Aviation Data APIs for Flight App Status Pages and Alert Feeds
- VariFlight DataWorks Aviation API Documentation
