FlightXML3 - AirportBoards - status and status_code


Looking at the FlightXML3 AirportBoards…


  • status_code is missing from many flights
  • status of “En” should be “En-Route”

I’d love to get a status_code on every flight returned by AirportBoards; I’d also love to get documentation of possible values for status and status_code. So far I’ve pieced this together, but, I suspect there are fringe cases that I haven’t seen yet… “Diversions” at least.

0 = scheduled
1 = landed
2 = departed / en-route



At the moment we’ve actually removed the status_code and state_code. state_code was something for internal use. If the status_code is more useful than a textual description we can look at adding it back in and documenting the various options.


As long as the plain-text status sticks around, the others can be dropped without any issue on my end; I’d just like to know what all of the possible values are so I can accommodate them with my app.


We’ll have to put in a fix for En Route, but here are the possible status codes:

result unknown
Taxiing / Left Gate
Scheduled/Delayed (For not yet departed flights)
Delayed (For departed flights)
Landed / Taxiing
Arrived / Gate Arrival
En Route
En Route / On Time

I may have to amend that list some as we fix the bugs in that procedure call, but this should be pretty close to what you’ll end up seeing


Thank you!


I’m having the same problem in with the “status” in french. It seems that we only receive the first word for multi-words status (ex: “En” for “En vol”).

Also, I receive the status “A” for a flight in Arrivals. Can you give me the list of status codes in french so I can figure out what “A” means.



Was just wondering if there’s a current list of the terms that the Status may return for FlightInfoStatus queries. I think I caught one flight with a status of “Just Landed”, so was curious if anything was new/changed from the list above.



The “status” string should not be mechanically parsed, if that is what you are planning. It is algorithmically generated out of multiple substrings and the format may change slightly over time, particularly if we make changes to localization.


Oh, now I understand what the string “result” means. It means “result unknown”.

To what extent do you try to guess the status? For example, if a flight x with tail t to A is unknown, but shows up as a departure from airport A, do you say the previous flight must have landed at A?


Currently, subsequent flights are not used to alter the status of previous flights that have already been marked as “result unknown”.

Origins and destinations may be assumed if we don’t have a flight plan but we receive positions for the flight that are reasonably close and reasonably low altitude to an airport.


I was wondering why some of my flight results weren’t updating correctly again.

I can understand the need for a field that behaves as you’re describing (plain-language status, subject to undocumented change based on lots of variables on the ground that are sometimes unique) however, we absolutely need some sort of reliably parsible status field that can adequately handle most flights and has documented values somewhere outside of this thread. What you’ve posted already seems like it’d cover most cases - perhaps those could be used as foundation of an additional status field that isn’t subject to change?

  • Scheduled
  • Unknown
  • Cancelled
  • Diverted
  • Left Gate
  • Returned to Gate (at origin)
  • Scheduled/Delayed (For not yet departed flights)
  • Delayed (For departed flights)
  • Arrived
  • Landed / Taxiing
  • Arrived / Gate Arrival
  • En Route
  • En Route / On Time