Flight Information Display System (FIDS) — How to Build a Live Departure Board

Flight Information Display System (FIDS) explained. How airport departure boards work, FIDS components, how to build a flight information display with live schedules, gates, terminals and delays using a flight data API.

Sergey St.

Published on Jun 4th 26

Share:

• 
• 
• 

What Is a Flight Information Display System (FIDS)?

A Flight Information Display System, commonly known as FIDS, is the network of monitors and digital displays you see throughout an airport that show real-time flight information. Every screen displaying departures and arrivals — at check-in counters, in waiting lounges, at gates, in baggage claim, in hotel lobbies near the airport and in corporate offices — is part of a FIDS infrastructure.

FIDS displays show passengers and staff the essential operational data they need: which flights are departing or arriving, the airline operating each flight, the destination or origin, the gate or terminal, the scheduled time, the actual or estimated time, the current status (boarding, departed, delayed, cancelled, landed), and increasingly the baggage carousel for arriving passengers.

Behind every FIDS display is a data pipeline that aggregates flight schedule data, applies real-time status updates, formats the information for the specific display type and refreshes the content. Whether you are an airport operator, a hotel near the airport offering a courtesy departure board for guests, a corporate office wanting to display flights for traveling employees, or a developer building a flight tracking application, the underlying data requirements are the same — and the AirLabs Schedules API provides exactly this data.

"FIDS is one of the oldest and most reliable data products in aviation. Every traveler has used one. Yet building a FIDS-style display from scratch still requires aggregating data from airlines, airports and ground operations — exactly what a flight schedule API delivers in a single endpoint."

How a Flight Information Display System Works

A traditional FIDS infrastructure at a major airport receives data from multiple sources: airline reservation systems publish flight schedules; airport operations systems broadcast gate and terminal assignments; ground handling systems report boarding and departure events; air traffic control provides actual takeoff and landing times. These sources feed into a central FIDS database, which then distributes the consolidated data to all the displays in the airport.

For developers building a smaller-scale FIDS — for a hotel, a corporate office, a private terminal or a custom application — accessing all of these sources individually is impractical. Instead, a flight data API provides the consolidated stream of departure and arrival data already aggregated from these sources. The AirLabs Schedules API returns this data through a single REST endpoint:

https://airlabs.co/api/v9/schedules?dep_iata=JFK&api_key={API_KEY}

The response contains every scheduled departure from the requested airport with the complete data needed for a FIDS display:

[{
  "airline_iata": "BA",
  "airline_icao": "BAW",
  "flight_iata": "BA6984",
  "flight_icao": "BAW6984",
  "flight_number": "6984",
  "cs_airline_iata": "AA",
  "cs_flight_iata": "AA2421",
  "dep_iata": "JFK",
  "dep_icao": "KJFK",
  "dep_terminal": "8",
  "dep_gate": "B36",
  "dep_time": "2026-05-28 19:53",
  "dep_estimated": "2026-05-28 22:10",
  "arr_iata": "LAX",
  "arr_icao": "KLAX",
  "arr_terminal": "4",
  "arr_gate": "44B",
  "arr_baggage": "5",
  "arr_time": "2026-05-28 22:52",
  "arr_estimated": "2026-05-29 01:09",
  "status": "scheduled",
  "duration": 359,
  "delayed": 137
}]

Every field a FIDS display needs is here: the airline (airline_iata), the flight number (flight_iata), the destination (arr_iata), the gate (dep_gate), the terminal (dep_terminal), the scheduled time (dep_time), the estimated time (dep_estimated), the status (status) and the delay in minutes (delayed). Even codeshare information is included via the cs_airline_iata and cs_flight_iata fields — essential for correctly displaying flights that are marketed by one carrier but operated by another.

Core Data Fields for a FIDS Display

A typical FIDS departure board shows a specific set of columns, and each column maps directly to a field in the Schedules API response:

A FIDS display for arrivals uses the same data but presents the arrival-side fields: arr_terminal (terminal where the plane parks), arr_gate (arrival gate), arr_baggage (baggage carousel) and arr_time / arr_estimated. The Schedules API returns both departure and arrival data, so a single API integration can power both departure and arrival boards.

FIDS Status Codes and What They Mean

One of the most important elements on any FIDS display is the flight status. The AirLabs Schedules API returns standardized status values that map to the colored indicators travelers see on airport boards:

For the on-time indicator, your FIDS application checks the delayed field — if it is 0 or close to 0, display "On Time"; if it shows a delay in minutes, display the new estimated time using dep_estimated. This is exactly how airport FIDS displays operate.

Codeshare Handling in FIDS Displays

One of the most challenging aspects of building a correct FIDS display is handling codeshare flights. A single physical departure can be marketed under multiple flight numbers by different airlines — the same plane might be listed as BA6984 (British Airways), AA2421 (American Airlines) and IB7104 (Iberia) on different airline displays.

Airport FIDS boards typically show one row per physical flight, with all marketing airlines listed in the codeshare column. The AirLabs Schedules API supports this by returning the cs_airline_iata, cs_flight_iata and cs_flight_number fields whenever a flight is operated under a codeshare arrangement.

For the example flight shown above, the cs_airline_iata field is "AA" and the cs_flight_iata is "AA2421" — telling your display logic that this departure (sold as BA6984) is actually operated by American Airlines flight AA2421. Your FIDS rendering can choose to display either the marketing airline, the operating airline or both, depending on the use case. For passenger-facing displays, regulators typically require both to be shown. 

Who Uses FIDS Displays Beyond Airports

The FIDS pattern — a live departure or arrival board — is not limited to airport terminals. Many organizations build their own FIDS displays for specific audiences:

Hotels and Hospitality

Hotels located near major airports often install courtesy FIDS displays in their lobbies. Guests can check their flight status without opening an app, helping them plan their departure to the airport. The hotel front desk can also see arrivals to anticipate when guests will check in.

Corporate Offices

Companies with employees who travel frequently install FIDS displays in office lobbies, executive floors and travel departments. The display shows current flights for traveling employees, helping the travel desk and assistants stay informed without checking individual booking systems.

Private Aviation Terminals and FBOs

Fixed Base Operators (FBOs) serving private and business aviation use FIDS displays to coordinate ground handling, catering and ground transportation for arriving and departing private jets. The same Schedules API data, filtered by specific ICAO codes, powers these specialized displays.

Ride-Sharing and Ground Transportation Hubs

Taxi stands, ride-share waiting areas and limo company dispatch centers near airports use FIDS-style displays to coordinate driver dispatch with actual flight arrivals. By monitoring the arr_estimated field, dispatch systems route drivers to the airport at the right time, reducing idle waiting.

Travel Applications

Mobile and web travel applications often include a FIDS-style screen showing all departures from a chosen airport. This is a common feature in airline apps, airport apps, travel itinerary tools and trip planning platforms. The same API endpoint that powers an airport's physical FIDS can power your mobile app's departure screen.

Building a FIDS Display with the AirLabs Schedules API

Building a working FIDS display requires three components: a data source, a refresh strategy and a rendering layer. The AirLabs Schedules API handles the data source, your application logic handles refresh, and any web technology can handle rendering.

Data Source

A single API call returns the complete departure or arrival board for any airport:

https://airlabs.co/api/v9/schedules?dep_iata=LHR&api_key={API_KEY} — departures from Heathrow

https://airlabs.co/api/v9/schedules?arr_iata=LHR&api_key={API_KEY} — arrivals to Heathrow

The Schedules API returns results up to roughly 10 hours ahead, so a FIDS display refreshing on a short interval always shows current and upcoming flights. The _fields parameter lets you request only the fields your display actually shows, reducing response size for high-frequency polling.

Refresh Strategy

Update frequency on the AirLabs platform varies by data type — some fields refresh within seconds (aircraft positions, status changes), while others update less frequently (gate assignments, terminal changes, scheduled times). In practice, AirLabs flight data refreshes anywhere from 5 seconds to 1 minute depending on the specific information.

It is also worth noting that any third-party flight data aggregator — including AirLabs — typically reflects airport-published data with a lag of 1–10 minutes compared to the displays at the airport itself. This is normal because airlines and airports publish updates through multiple channels at different speeds, and some fields like the departure gate are only known once the aircraft is parked.

For your application, a polling interval of 30–60 seconds is a reasonable starting point for a passenger-facing FIDS — frequent enough to keep gate and delay information current, but not so frequent that you make unnecessary API calls.

For high-frequency updates without polling, the AirLabs Flight Alert API sends webhook notifications when specific tracked fields change (gate, terminal, status, delay). This is the most efficient pattern for production FIDS deployments — your display updates only when something actually changes, rather than re-fetching the entire schedule on a timer.

Rendering

The rendering layer is purely a frontend concern and depends on your platform. A large airport-style display might use a TV-style web page with high contrast and large fonts. A mobile app might use native UI components with scrollable lists. A hotel lobby kiosk might use a fullscreen browser pointing at a single HTML page. The data layer is identical in all cases — the difference is purely in how you display the same Schedules API response.

Combining FIDS Data with Other AirLabs Endpoints

The FIDS display becomes richer when you combine the Schedules API with other AirLabs endpoints:

• Add airline logos and names — query the Airlines Database to retrieve full airline names from the IATA code. This is essential because the API returns airline_iata but your display likely needs to show "British Airways" not "BA".
• Add airport names — query the Airports Database to convert the arr_iata code into a destination city name and airport name for the display.
• Add aircraft information — use the Flight Info API to get aircraft type (Boeing 787, Airbus A350) for each flight, useful for some FIDS displays.
• Show timezone-adjusted times — the Airports Database includes the timezone field. Combined with the Timezones Database, you can display times in local airport time, your user's timezone or both.
• Filter by terminal — for multi-terminal airports, filter the Schedules API response by dep_terminal to show only flights from a specific terminal. This is how airport FIDS displays in Terminal 5 show only Terminal 5 flights.

A complete FIDS application typically integrates four or five endpoints to provide a polished, complete user experience. All of these are part of the AirLabs API and accessible with a single API key.

Flight Information Display System for Developers

If you are a developer building a flight information display — for a hotel, a corporate office, an airport terminal, a private terminal, a mobile app or a web application — the AirLabs Schedules API provides everything you need.

• Live Schedule Data — current and upcoming departures and arrivals with status, delays, gates and terminals, refreshed at intervals appropriate to each data type.
• Codeshare Support — the cs_* fields ensure your display correctly identifies marketing and operating carriers for codeshare flights.
• Single REST Endpoint — one API call returns the complete board for any airport. JSON response, simple integration in any language.
• Webhook Alerts — the Flight Alert API supports webhook-based status changes, eliminating the need for high-frequency polling.
• Field Selection — use the _fields parameter to request only the data your display shows, reducing response size and bandwidth.
• Free Tier Available — start building immediately with the free API plan. No credit card required.

Supported API Features

Our Developer API allows you to create a custom experience for your users and increase the value of your product:

• Schedules API with live departures and arrivals, gates, terminals, status and codeshare fields.
• Flight Alert API for webhook notifications on status, gate, terminal and delay changes.
• Airlines Database for converting IATA codes to airline names for display.
• Airports Database for converting IATA codes to airport names and timezones.
• Flight Information API for individual flight details including aircraft type.
• Real-Time Flights API for live aircraft positions linked to scheduled flights.
• Routes Database for showing typical routes from an airport.
• Timezones Database for local time conversion across display locations.

You can try it right now without any obligation! Get a free flight API plan and see for yourself that we have exactly the data you need!

If you need more information, don't hesitate to contact us. We are always happy to chat with our customers and are sure to find a customized solution for each request.