Call for flight returns null using API but shows fine on web

Several flights do not show any data.
examples: DL153, DL173, KL1628, DL67, DL185

I have tried the ICAO and IATA with same null results

I go the FA website and type in either and it comes right up.

How do I get the API to include these flights… also, am I being charged for these null flights?

thanks!
Joe

Can you provide some examples of the URLs you are requesting for those requests? It’s possible you have accidentally malformed the request in some way.

All requests are charged the minimum of one result regardless of whether the result is “successful” or not, since there is still an operational cost for us to execute a query. This policy also serves to discourage wastefully frequent polling by applications.

@bovineone ,

I am doing 30-40 flights back to back and it is just a few that are not behaving:

https://aeroapi.flightaware.com/aeroapi/flights/DL67?start=2022-09-15T12:15:00&end=2022-09-15T14:15:00

https://aeroapi.flightaware.com/aeroapi/flights/DL153?start=2022-09-15T11:25:00&end=2022-09-15T13:25:00

https://aeroapi.flightaware.com/aeroapi/flights/KLM1628?start=2022-09-15T05:40:00&end=2022-09-15T07:40:00
(yes, i have also tried just KL1628 as well as DAL for the DLs)

This one works just fine:
https://aeroapi.flightaware.com/aeroapi/flights/KL6027?start=2022-09-15T08:00:00&end=2022-09-15T10:00:00

Have you tried omitting the start/end arguments and seeing if the desired flight is returned within the multiple results that are returned? We also recommend specifying timestamps in UTC timezone (and ending with a trailing “Z” is the iso8601 formatted string).

Yes, i have,…maybe you have different results? and yes these are UTC times.
I have about 20 flights running through my app being updated every 20 minutes. Working great for all of them except these 3-4 flights.

Your +/- 1 hour time box in the first few examples you provided appear to be supplying the timestamp arguments assuming local time.

For example with that DAL153 flight, the scheduled block out time is 2022-09-15 12:25PM CEST (2022-09-15 10:25:00 UTC).

In this case, I’d recommend trying maybe:

https://aeroapi.flightaware.com/aeroapi/flights/DAL153?start=2022-09-15T09:25:00Z&end=2022-09-11T13:25:00Z

Similarly, for DAL67 the scheduled block out time is 2022-09-15 11:15:00 UTC so instead of:

Try this:

https://aeroapi.flightaware.com/aeroapi/flights/DAL67?start=2022-09-15T10:15:00Z&end=2022-09-15T12:15:00Z

ahhh! yes yes, it was the UTC Offsets! I was using a table found on Wikipedia to lookup the offset for each timezone and that turns out not to be the most reliable source. Off by an hour in this case.
Do you have a recommend site or API for getting accurate UTC offsets? That means everything to make this work. Thanks for looking into this for me!

You can use /airports/id to look up individual airport codes and get the timezone value in the response. That is the IANA TZ database identifier that you can use to translate timestamps between UTC or local timezone.

(I recommend locally caching responses from our /airports/id method to avoid needing to call it for the same airports shared by different flights.)

As I suggested earlier, you can also just omit the start/end arguments entirely and programmatically sift through the multiple flight results returned to find the one you’re looking for (assuming it’s always going to be a recent one that is in the first page of results returned).

Yes, I already use the airport/id to get the TZ… then i cross lookup the TZ with the chart I saved from Wikipedia to get the Offset of that TZ… the offset is most important part and which I do not see returned from any FA API.

I am checking dozens of flights every 20 mins for a full day… need to get the most current info to update us on flight departures/delays… My app runs through a list of flights by student and more than one student can be on the same flight so i really don’t need to call that same flight 4-5 times… can you direct me how to cache flights so i don’t waste calls?

I like your suggestion about the start/end arguments… it made me think to just automatically back up every start time by 1 or 2 hours in order to capture the one needed and that will fix any error/discrepancy i have in UTC offsets.

Thanks!
Joe

We intentionally don’t provide UTC offsets because they are only accurate at the moment they are generated (daylight saving time changes happen at different moments for each timezone and regularly change due to local legislation). Knowing the IANA TZ database identifier is the preferred solution, since it allows you to convert a timestamp on-demand based on the DST rules that were in effect at the time of the timestamp. (Our internal strategy is to generally store and compare only UTC timestamps, and render them as localtime only for display purposes.)

right, the TZ is valuable to find the rules for the TZ in question? i used a chart on Wikipedia but it’s not 100% accurrate. How would you recommend converting the timestamp based off just the TZ? You have to know if a TZ is in DST or not.

https://www.iana.org/time-zones

There are also libraries for many platforms to let you use the IANA tz database (aka: zoneinfo). See the wikipedia page for more info: tz database - Wikipedia