Question about calls billing of the AirportBoards endpoint


We perform one request to the “AirportBoards” endpoint every 2 hours, with the intention to only use one API call per request. When I call up Billing Information ✈ Recent Activity - Flight Status API / Flight Tracking API / FlightAware API - Commercial Services - FlightAware, I see that sometimes up to 4 calls are billed per request. I’d like to understand why this is the case, and how I can avoid to go over 1 call. The 2 types that I’m interested in are “enroute” and “scheduled”.

Currently we use the default “AirportBoards” request with no parameters except of “airport_code”

What parameters do I need to set to make sure that I only use 1 call per 2 hours?

Are you making a call for each individually?

Thanks for your answer.

We are making one call without any additional parameter beside “airport_code”. All 4 types are returned in the result. Is it possible to only query the 2 endpoints we need within one call, and keeping the count to 1?

It’s buried in the forums here somewhere, but, yes, each HTTP call to the AirportBoard API counts as one billable query, as long as you don’t get more than 15 flights in each of the enroute, scheduled, etc. results.

Hello ottergoose, thanks for your reply. Do you mean that as soon i receive more than 15 flights with all 4 types counted together, it will count more than one?


This response with 10 flights per type was billed with 3 calls.

I guess what i need to to is splitting the calls into one for enroute and one for schedule, and limiting both to 15. This should make sure they only count as one each.

Arrivals, departures, enroute, and scheduled can each contain up to 15 flights (that’d be up to 60 flights between the four) and the API call should count as 1 billable query.

Hmm, this is not how i experienced it. I agree with you that it should behave like that, but from what i see it isn’t.

40 flights got billed for 3 calls, which is in the (3 x 15) range. I also experienced getting billed for 4 calls with a single AirportBoards response. Back then i had no parameter set for howMany, so it was default (15).

I am seeing now that the majority of the results are 1 query. Were you able to resolve the issue?

@cbw I am still trying to understand why not every request is billed with 1. We make the exact same request every 2 hours, and if @ottergoose was right with his assumption, this should always just cost 1 call.

The only parameter changed since the beginning of this topic is “howMany”, which is now set to 11.

Do you maybe have more insight to the API connection details from our IP How does it explain that sometimes it costs 2 calls?

FWIW, my application uses a healthy volume of FXML3 airport board calls - I just did a quick audit to verify my requests jive with FlightAware’s reporting (which I should have done before, but hadn’t), and it looks pretty solid; in a time period with over 10,000 requests, the count discrepancy was just 1 - an error rate of less than 1/10 of 1%.

In other words, I’m not experiencing the same issue with my FXML3 AirportBoard queries as you are - will be interesting to see what the issue is.

Let me have someone check it out. Realistically, the howMany shouldnt matter as long as it is under 15. Blank/Deafult would provide that limit

@cbw Thanks for this!

After looking at the data. We are seeing 2 calls made that are hitting 2 different servers. These calls are made at the same time but would start and end with the same server. Therefore, if we see 2 calls hitting 2 different servers, that would indicate that they are both unique calls made, and therefore, you are seeing the 2 calls charged.

@cbw Thanks for you detailed answer. I will make sure that only 1 call is made at the time on our side. The script is very simple and executed via cronjob, so I wonder what the issue could be. Thanks for clearing things up for me!

@ottergoose Also thanks to you for the participation in this. It’s very clear now that the issue is somewhere on our side.

So to clarify:

  1. if you request all 4x types with a howMany=15 you can get 60 flights for your 1x billable call.

  2. if you request say 1x type (say scheduled) with a howMany=15 you can get 15 flights for your 1x billable call.

  3. if you request say 1x type (say scheduled) with a howMany=60 you can get 60 flights for 4x billable calls, or are you allowed up to 60 flights total per call?

It would be most fair if for 1x type you could et up-to 60 flights for the 1x call as you have no idea if you going to say run out of depleted flight before the schedule or vice versa.

Optimally if interested outbound (scheduled & departed) you query both with howMany=30 and when nextOffset=-1 for one was retuned you’d drop that for subsequent queries and call for the other with howMany=60 with each call, costing the same 1 call each!?

In your case three if 60 flights are returned that is 4 billable queries. If less than 60 are returned despite the howMany setting then the normal results divided by 15, rounded up, math applies. The results count used for the billable query calculation in boards is always the largest result count from the requested boards subtypes.

Apologies for bringing this up again.

I’m aware that a single call for all types with howMany = 15 counts as one billable call, even though 60 flights are returned.

But what if I set howMany to 30? Will that count as two calls?

I’m aware that a single call for all types with howMany = 15 counts as one billable call, even though 60 flights are returned.

Setting howMany = 15 will return a maximum of 15 results and only ever count as a single query. This is also the default value if howMany is not specified. If there are more potential results it will be represented as the next_offset that can be used to request the next “page” of results as a new query.

But what if I set howMany to 30? Will that count as two calls?

If the response contains 16 to 30 results two queries will be billed. If 15 or less results are returned then one query will be billed. So, at least one query will be charged, but if the howMany cannot be fulfilled the charge count is based on the amount of results.