We built an API that supports entering of Alerts via the FlightXML2/SetAlert interface. It’s been up and running for about a year but the return from the FlightAware API has at least two interesting features. The main criticism is that if we submit a specific flight we would like to Alert on using Airline Code/Tail Number such as ASA55 (Alaska Airlines 55) for the ident value there appears to be a “Best Match” algorithm set up on the FlightAware end that sets our alert but sometimes pairs it with an Airline we are not interested in. This is similar to how the UI works I believe, but from the coding side of things this is not always the desired result. I think it is there in the FlightAware UI to handle the “operated by” type flights were the user may be unaware of how the flight is entered in the database. This seems to specificallly occur on our end where there has been mass mergers / rebranding of airline names and the data being submitted by operators to FAA may be mixed up to start with. In our world in Alaska the larger regional airline known as ERA (ERR) but historically based on Frontier Flying Service (FTA) with subsidiaries of Hageland Aviation Services (HAG) are now operated as Ravn (RVF).
For instance today March 30th 2015 we would like to set an alert on RVF807 for an ident code. We submit it to the API - but the Alert that comes back is set for an ident of ERR807. Both these flights are in the FlightAware UI - but ERR807 (the old name) has nothing scheduled for the future and nothing listed in the last few months.
In another strange but specific case setting up an alert for RVF823 remaps the alert to watch for ERH823 - but ERH is ERA Helicopters which has long been a separate company from ERA Alaska. Both these flights exist in UI, but SetAlert interface always sets to ERH823.
Please consider giving the API an “override” feature so that we can setup an alert on a specific ident - WITHOUT having the flight remapped. We propose that the UI can be studied by user to figure out what flight they really want to alert on is.
The other problem we have with the API is that if we are trying to set an alert near the end of the day for a flight later in the evening local time and UTC time is already on the next day we can’t seem to sneak in the flight via the API - we generally end up with the API “rolling” the alert to the next day. This may be an understanding problem with what the time basis is of the API but we have sort of learned to try to set all our alerts for the day before UTC time as rolled into the next day. For instance in Alaska we are currently 8 hours behind UTC time. As long as via the API we setup alerts for undeparted flights leaving today (local epoch time) before 4pm local time we can get an alert back for our current day. However if we try to setup an alert for a flight leaving at 8pm AFTER 4pm local time we can only get the alert to respond to the flight the next day. Does this sound familiar?