Update the Flight Information Display System (FIDS)

Travelers expect to see the latest information for their flight on screens at the airport and their hotel.

This article explains how you can use the Cirium Flight Information Display System (FIDS) API to update flight information displays with the latest information.

FIDS Screen


  • Airlines responsible for FIDS screens in airports
  • Airports
  • Hotels displaying a FIDS screen in their hotel lobby or on in-room televisions


FlightStats APIs

Flight information provided by FIDS

The FlightStats APIs typically provides the following information:

  • Primary airline IATA or ICAO code
  • Flight number
  • The city of origin and/or destination (potentially including intermediate stops)
  • The expected arrival or departure time and any delay information
  • Status of the flight (Landed, Delayed, Boarding, Departed, etc.)
  • The arrival and departure gate number
  • Codeshare information (different flight numbers associated with the codeshare partners of the flight)

Note that the FIDS API can provide more information than what's listed above.

How to use the FIDS API

Here are the four steps you take to use the FIDS API:

  1. Get an account key
  2. Determine the requirements of your FIDS screen
  3. Determine the fields needed to request
  4. Make the request and consume the results

1) Get an account key

The FlightStats APIs) are premium APIs available through a contract plan. It's also available with limited features on the evaluation plan. See Get Evaluation Account to get an evaluation, or contact us to get the FIDS API added to your contract. FIDS is a part of the FlightStats API platform. See Getting Started for information about the request and response approach of this platform.

2) Determine the requirements of your FIDS screen

Here's a list of questions you'll need to answer as you determine what you want your FIDS screen to display.

Arrivals or departures?

There are two FIDS API endpoints: one for departures and one for arrivals. They're differentiated by a path parameter at the end of the call. The arrivals endpoint uses the arrivals path parameter. The departures endpoint uses the departures path parameter.

Some of the data items are only appropriate for certain types of displays.

For example, arrival boards might display baggage claim information, whereas upline airport departure boards might show downline airport names, boarding information, and weather at the destination.

Do you want the information filtered for a specific terminal?

If the FIDS screen is located within a terminal, you may want to only display departure information for that terminal. In some cases, airports or airlines are only responsible for the data within a given terminal, whereas flight information for other terminals at the airport are the responsibility of other airlines.

The results may be filtered to a terminal by setting the terminal attribute to a specific terminal number.

For example:


Do you want the information filtered for a specific airline?

If the FIDS screen is located within an airline lounge, a terminal that's specific to an airline, or an airline-specific kiosk, you may want to filter by only the airline or airlines involved. 

Filtering by the airline is done by specifying the airline codes (these are FS codes) in the includeAirlines request attribute. Multiple airlines can be specified by using a comma-separated list.

For example: includeAirlines=AA,AS will only return flights operated or marketed by American and Alaska.

Do you want to filter out cargo flights?

In most cases, FIDS screens only display information for flights that carry passengers. Showing the departure information of cargo flights isn’t very useful and only adds to the visual confusion that travelers must filter through when trying to find their flight.

The request attribute excludeCargoOnlyFlights can be set to true to indicate that cargo-only flights should be excluded. The default is false.

Pro tip

Unless your application has specific cargo needs, we recommend filtering out cargo-only flights. We filter this based on the airline code. It won't necessarily filter cargo flights that are operated by a carrier that also operates passenger flights. In this specific case, you'll need to add additional filtering based on flight numbers to exclude cargo-only flights.

Do you want to filter out specific airlines?

There might be cases where you don't want certain flights displayed. The flights can be filtered using the excludeAirlines request attribute. Multiple airlines can be specified by using a comma-separated list.

For example: excludeAirlines=AA filters out any flight where airlineCode=AA.

Please see information about codeshares below, as it is still possible that you'll receive information about flights where the operating carrier or primary marketing airline is the airline being filtered. Excluding the airlines doesn't exclude the codeshare flights from displaying.

You can't use excludeAirlines and includeAirlines in the same request.

Are you displaying codeshares?

Codeshares are agreements between airlines where two or more airlines market the same flight as if it were their own flight. One airline operates the flight but other airlines partner with the operator so that they can sell tickets to passengers for that flight.

Travelers might or might not know anything about the codeshare. As far as they're concerned, they're flying on a particular flight number and that’s the flight number they will look for on the FIDS screen. To satisfy this need, you'll want to display some information for the codeshares on the FIDS screen. Some common patterns include:

  • Showing codeshare flights as if they were flights operated by the codeshare. In this case, every flight (codeshare or not) has a line on the FIDS board.
  • Showing the primary flight number and then rotating codeshare numbers on the same line. In this case, the primary flight number is displayed on a line on the FIDS boards and after a couple seconds, the number is replaced by a codeshare flight number or multiple codeshare numbers and then rotated back to the original.
  • Showing the primary flight number and then including the codeshare information as a smaller line under the primary flight number. In some cases, the codeshare flight numbers are rotated on the second line.

Adding to this confusing situation, a flight might be operated by a carrier on which travelers can’t purchase tickets for. This is common with regional flights operated on behalf of a primary marketing airline, but the actual flight is on an airline owned by a partner. Examples include Alaska Airlines flights operated by Horizon Airlines or Delta Air Lines flights operated by SkyWest. In these cases, it’s important to make sure the primary marketing carrier is what is displayed, not the operating carrier.

The FIDS API can return codeshare information.

Here are some examples that illustrate how different request attributes affect this:

In this example, we're showing departure information from PDX (excluding cargo-only flights) and adding several attributes to requestedFields to show everything that's known about these relationships. (Substitute your app ID and key to run the example)


A snippet of the response looks like this:

In this example, the first flight is AS 564. This flight is an Alaska Airlines flight operated by Alaska, of which there are no codeshare relationships. Notice the isCodeshare is false.

The second flight is DL 1062. Delta operates this flight. Notice the isCodeshare is false. Delta however has codeshare relationships with Korean Air and KLM for this flight. The next 2 flights in the results are these codeshares. There are records for KE 6799 and KL 6214.

Note that for both these records isCodeshare is true, and the operator and primary carrier is Delta. However, the airlineCode and flightNumber returned are for the KE and KL flights. The FIDS API has done the work for you, so that if you display airlineCode and flightNumber you don’t have to worry about the codeshare relationships.

The next flight is AS 3399 operated by SkyWest on behalf of Alaska. The FIDS API doesn't return a row for Skywest, as a traveler couldn't purchase a ticket from Skywest for it. The isCodeshare flag is true because there is a codeshare relationship, but a traveler wouldn't look for the Skywest flight number but Alaska instead.

Note also that Alaska has a codeshare relationship with American and the next row returned is the American flight. If you only display airlineCode and flightNumber you don’t have to worry about the codeshare relationships.

This works well for displays that show codeshare flights as if they were real flights. But what about the other two use cases where the screen intelligently combines the information into a single row or a subrow? In this case set the request attribute includeCodeshares to false (the default is true).

When set to false, additional rows of information are not automatically returned for the codeshare flights. But codeshare information is still attached to the main flight if you include codeshareAsCodes in the requestedFields.


A snippet of the response looks like this:

As you consider this response, you can see that flight information is still returned for AS 564 (with no codeshare relationship), DL 1062 and AS 3399. However, there are no records returned for KE 6799, KE 6214, or AA 7410. The codesharesAsCodes attribute shows this information and can be used as values to rotate in with the primary flight or to display under the primary flight.

Codeshare settings impact how includeAirlines and excludeAirlines work as well. We know, for example, that there is a KE flight that codeshares with DL.

Suppose you want to display all KE flights but still have includeCodeshares set to false.


The response looks like this:

Because the KE flight is a codeshare, it isn’t returned if includeCodeshares=false.

If you issue the same request with includeShares=true (or blank), a snippet of the response looks like this:

The KE flights are all returned, but no rows for the original DL flight are returned.

With codeshares on, if you were to exclude DL, rows for the KE flight are returned with information about the DL codeshare relationship, but no Delta flights are returned as individual flights.

Pro tip

With codeshares, use the logical FIDS fields (see below) such as airlineCode, flightNumber, etc. that we've created for you instead of the more specific fields such as operatingAirlineCode, primaryMarketingAirlineCode, etc. While you're learning how the API works, it's a good idea to request that many of the fields are returned, as illustrated in this example. Once you verify that the logical fields act as you require, you can simplify the request and have a more compact payload.

Do you want to show upline or downline information?

A single flight number may depart and arrive at multiple airports in a single day. As an example, a traveler is flying PDX to MIA but on a flight that has two stops along the way. The first stop is in DEN, the second at BWI. The carrier and flight number are the same. The traveler doesn't depart the plane but waits at DEN and BWI for other travelers to depart/board the plane. The individual flight segments for this flight are:

  • PDX->DEN
  • DEN->BWI
  • BWI->MIA

A traveler departing at PDX for MIA might not remember they have these stops along the way and look at the FIDS board for their flight number with a destination of MIA. On the arrival side, an individual meeting the traveler might not know that the traveler’s flight had stops along the way. They only know the traveler is coming from PDX.

The FIDS API returns individual flight segments. So, if you were creating a departures board for PDX and only using the defaults, the FIDS API would return the PDX->DEN flight but no flight for PDX->MIA. Calling FIDS with the defaults for MIA arrivals would show the BWI->MIA but not any information for PDX.

To satisfy the requirements to show the upline (the various airports a flight departs from before reaching an arrival airport) or downline (the various airports a single flight goes to after departing a specific airport), you need to add uplineAirportNames, uplineAirportCodes, downlineAirportName, or downlineAirportCodes in requestedFields.

Here's an example of a call that achieves this:


A snippet of the response looks like this:

In this example, we requested Southwest Airlines departing from PDX. Two of these flights have multiple airports they are arriving in that day. In the case of WN5862, the flight is PDX->DEN->MDW. In the case of W2342 the flight is going PDX->OAK->BUR->PHX->HOU.

What you do with this information depends on the requirements for your FIDS screen. Some options include:

  • Showing the downline flights as if they were direct flights. In this case, your code needs to create individual records for each additional segment (OAK->BUR, BUR->PHX, PHX->HOU in the case of WN 2342) and show each row on your FIDS screen.
  • Showing the next destination and then rotating additional downline or upline airports on the same line on the FIDS screen every couple seconds.
  • Showing the next destination and then including the downline or upline information as a smaller line under the next destination. In some cases, this information is rotated on the second line instead of listing each out.

How many flights do you want to display?

Unless the FIDS screen is for a small airport, you'll probably want to constrain the number of flights that the FIDS API returns. There are three request parameters that the FIDS API uses to control the number of flights returned:

  • timeWindowBegin
  • timeWindowEnd
  • maxFlights

By default, the FIDS API returns the most relevant flights based on the current time at the airport and the size of the airport. For small airports, the FIDS API will return most of the flights that depart around the current time or later in the day. For larger airports, the FIDS API only returns the next couple hours of flights. You can control the time window by specifying the number of minutes before and after the current time at the airport.

The default time ranges are based on the classification of the airport from 1 through 5, with 1 being the largest.

If a timeWindowBegin and timeWindowEnd isn’t specified in your FIDS API request, the FIDS API uses a default window of flights departing or arriving at an airport. The FIDS API looks at a window before and after "now" based on the classification or number of departures an airport has.

  • Class 1 airport: -1 to +8 hours

  • Class 2 airport: -2 to +16 hours

  • Class 3+ airport: -3 to +24 hours

FIDS calls Current Flight Status with the time window defined, so it behaves the same as Current Flight Status for that time window. This means it finds any flight that has any time field (actual, estimated, or scheduled) within the range.

To cut off the number of flights at a specific limit, use the maxFlights parameter. In this case, the FIDS API returns the flights it finds most relevant up to the maxFlights number.

Do you want to display airline logos?

FIDS screens typically display the logo of the airline on the row of flight information. We’ve collected logos for airlines and return a logo in SVG or PNG format based on what is requested. For example, to request SVG logos, add airlineLogoUrlSvg to the requestedFields string.

Pro tip

We provide the logos as-is and don’t guarantee that every airline has a logo, or that they are up-to-date. If a logo is missing or out-of-date, you may submit a helpdesk ticket so that we can address the issue. However, it might be more efficient for you to maintain a repository of logos yourself. Feel free to populate yours with ours. Having your own logos gives you complete control over them, and you may be able to satisfy a change request faster than we can. In addition, having your own repository means that network problems won't prevent you from loading logos from our Cloudfront distribution.

Do you want to display Boarding as a remark?

We don’t provide boarding status in-flight information. This is because airlines don’t reliably provide this information in their data feeds. Boarding messages are generally a timed event where the FIDS boards automatically display the Boarding status 15-20 minutes before scheduled departure. This helps motivate travelers to get to the boarding gate right away, which is what airlines want.

To display Boarding in the remarks fields, you need to indicate the number of minutes before departure for us to start displaying boarding information.

For example: boardingMinutes=30.

Pro tip

We include Boarding as an option for departure boards as a convenience. The logic might not work well in mixed-terminal use cases where, for example, international flights are included with domestic flights. International flights typically have earlier boarding times than domestic flights.

Do you want to display weather at the destination?

If you’d like to display information about the weather, we provide four fields that you can request to get weather information at the departure. These are:

  • temperatureC shows the air temperature in Celsius
  • temperatureF shows air temperature in Fahrenheit
  • weather is a string used to describe conditions at the airport, such as sunny, cloudy, etc.
  • weatherGraphic is a field we use to determine the appropriate graphic to display based on conditions at the airport

You can also display this information for departure airports on arrival boards if you’d like, though this is less common.

Pro tip

We determine the weather information using our METAR, TAF, and ZAF data. As with airline logos, you might want to cache weather graphics in your own local repository. This avoids potential network issues from trying to load logos from our Cloudfront distribution.

How do you want the information sorted?

Typically, FIDS boards are sorted in one of the following ways:

  • Destination for departures
  • Origin for arrivals
  • Airline and flight number

The FIDS API can sort the response by specifying a comma-separated list of fields to sort by, where the order of precedence is left-to-right.

For example, to sort by the airline name and flight number, specify the following:


For a departures board sorted by destination, the sort criteria would typically be:


How many minutes after scheduled departure or arrival should a flight be considered delayed?

We consider a flight delayed if it flight departs or arrives more than 15 minutes after its scheduled time.

If you'd like to change this default setting to 20 minutes, specify

in the request.

Do you want to use Runway Times to calculate delay?

We only use scheduled, estimated, and actual gate times to determine delay. In some cases, our data feeds might not include estimated or actual gate times, but will include runway times. To use runway times as a delay indicator when no gate times are available, specify useRunwayTimes=true in the request.

If a runway time is used to determine delays, it’s compared against the scheduled runway time. We only use runways if we don’t have actual or estimated gate times.

How do you want times displayed?

The FIDS API displays times using a 12-hour time format. To return information in 24-hour time format, specify the following in the request:


3) Determine the fields needed to request

The FIDS API response includes a variety of potential fields. To see all the information that can be returned, see the fidsData object that’s returned as part of 200 response in the API reference. You can customize the response to return everything, or only what you need by specifying a comma-separated list of field names in the requestedFields attribute of the request.

Here are the fields you can use to make a request:


Some of these fields are specific (for example: actualGateTime and actualGateDate) where some of the fields include logic to display what we think is the most useful information. The fields with this logic is sufficient for most FIDS screen needs.

Logical field
Fields considered
airlineCode, airlineName, flightNumber, airlineLogoUrlPng, airlineLogoUrlSvg
operatedAirlineCode, operatedAirlineName, operatingAirlineCode, primaryMarketingAirlineName, primaryMarketingAirlineCode, codesharesAsCodes, codesharesAsName, isCodeshare
We look at the operator and primary marketing airline, and the codeshare relationships. With this information, we determine the most logical airline and flight number to show. We also looks at the request to see if certain airlines should be included or excluded. We also check to see if includeCodeshares is requested.
airportCode, airportName, city, familiarName
originAirportCode, originAirportName, originCity, originFamiliarName, destinationAirportCode, destinationAirportName, destinationCity, destinationFamiliarName
We determine the most logical airport to show based on whether arrival or departures are being requested. In the case of an arrivals request, the airport shown is where the flight departed from. In the case of departures request, the airport shown is where the flight is headed.
currentDate, currentTime
scheduledGateTime, scheduledGateDate, estimatedGateTime, estimatedGateDate, actualGateTime, actualGateDate, runwayTimes
We determine the most relevant arrival or departure date and time (priority: 1. actual 2. estimated 3. scheduled), depending on whether you asked for arrivals or departures. If you’ve opted to use runway times, this might be a runway time if no gate time is available.
remarks, remarksWithTime, remarksCode
scheduledGateTime, scheduledGateDate, estimatedGateTime, estimatedGateDate, actualGateTime, actualGateDate, statusCode, delay
We look at the status of the flight as well as whether the flight was delayed to determine a remarksCode. We also consider some simple phrases that best describe the status of the flight.

The logical fields should satisfy most of your FIDS needs. However, if they don’t meet your specific requirements, you can request additional details about the flight and code your responses accordingly.

Pro tip

As you begin to work with the API, it might be beneficial to return all the data so that you can understand what is available and how the logical fields work better. Every field requested increases the size of the payload, so once you determine the exact fields, you need we recommend that you limit your request to include only the fields you need.

4) Make the request and consume the results

After determining your requirements and determining what fields you want to return, you must set up the request and consume the results.

The FIDS API supports both XML and JSON response formats. The type of response is controlled as a path parameter in the request.

returns departure information for PDX in JSON.

returns departure information for PDX in XML.

Other flight information options

In addition to FIDS, the Cirium FlightStats API platform offers several solutions to power these systems.

Flight Status by Airport APIs. APIs that provide departure and arrival information for a specific airport.

Flight Status Feed. A data feed of flight information that can power Airline or Airport operation database systems that in turn can power FIDS screens.

Multi-flight Alert APIs. A push-based system that sends updates for flights arriving or departing an airport or all flights for an airline. These alerts can feed into an Airline or Airport operation database systems that in turn can power FIDS


FlightStats. Home page for FlightStats APIs.

FIDS API. Information about the Flight Information Display System (FIDS) API.

Codeshare and wet lease relationships. Explains the relationships airlines have that let them share airplanes and routes.