MapFlightEx returns 200/OK but empty



I’m requesting this faFlightID CKK218-1512887144-airline-0020 that was returned by another method FlightInfoStatus, and the response I get is 200 OK with this as body:
“MapFlightExResult”: “”

The request:

My question is, why? And in these cases the request is counted for billing? In what cases requests are not counted for billing?

Hope you can help me.


Can any Flightaware staff member clarify me on this?


In some cases a map may fail to be generated, typically because of incomplete information about the flight, but also sometimes due to server error. You may be able to retry the request later (particularly if the flight was in the future) when we have received more flight details.

All requests made to our servers, successful or not, are counted as a billable event since it still consumes our server capacity to service the request. This ensures that users have an incentive to not repeatedly retry a failing/unsuccessful request until it succeeds for an aircraft that has not departed yet.


Thanks for the response @bovineone.
The specific flight was en route at the time of the request (I only query this method if is enroute given by FlightInfoStatus calculation. It should present the current flight position in a map image, right? When the flight is not enroute, it could return responses like this one, right? Or the method could return an image also in these cases?

Thanks for the clarification on billing. But, you also have to think, if the method is supposed (and have the conditions) to return the image map and for unknown reasons (client perspective) the method returns an empty body… we have being billed for nothing. We, at client side, can’t detect those cases…we don’t know…
and if we are quering that flight, lets say 15 to 15min during its flight time… we are consuming queries for nothing…
Hope you understand this…


What I’ve said doesn’t make sense to you?


Any Flightaware staff there? Can someone give a response for my concern?


We will attempt to make MapFlight/MapFlightEx return a non-200 response for more conditions that should have been detected as failures, making it easier for applications to distinguish.

However, we have no intentions of altering the long-standing billing policy of charging for requests at the time they are initiated, regardless of final outcome. As I stated earlier, this is necessary to provide a disincentive for the development of abusive applications that waste server resources on requests that generally fail.


The major problem is not really distinguish if there was a problem or not, because, I can check if MapFlightExResult is empty and then automatically I know there was a problem, or if I receive any other http status code other than 200 OK. The type of the problem is good to know, if it will help us (clients) solve the problem below.
The thing is: This particular flight was enroute (returned by FlightInfoStatus), so the query to the Map should return the map image, right? I admit that, if the flight is not yet departed or if it already arrived, then this method does not make much sense and it will always return an empty image (I’m assuming that, don’t know for sure if it works like that), but the flight was enroute, so it should return the image data…but in this case, it returned 200 OK, empty body… so it could be only some server error, I’m supposing that.

My problem here, is that I dont know when to stop/restarting querying, regarding your responses.
Imagine my application logic queries FlightInfoStatus 10 to 10 minutes, during the duration of the flight, having in count estimated/scheduled departure times and arrival times that I previously know.
So imagine my first query to the enroute flight, gives this response. How do I know If I’ll get any correct information in next requests till flight ends? Sometimes I will be querying for nothing, because of some type of server error, or because you don’t have correct /complete information to return the image (I’m wondering why, because the flight is enroute…). How do I know if it worths querying next time or not?

And I understand your concerns on protecting yourselfs against abusive applications that waste server resources on requests that generally fail, but you can implement other strategies on that, like for example: blocking temporarily IP address on abusive requests, or block account temporarily, or others… there are alternatives I guess…

Imagine I track 200 flights a day (170 with success)
6 queries per hour * 5hours of flight time (average)*170 flights * 30 days = 153000 queries

Imagine how many requests are billed for nothing during an average of 5 hours flight time x 30 tracked flights a day that fails on obtaining map (average)(adjusting flights to more, and is scary)
6 queries per hour * 5hours *30 flights * 30 days = 27000 queries

Total average: 180000 queries month only to Map Method. So because we are in this range: 100,000 - 249,999, then each class1 query will cost: $0.0040
Bill amount for nothing: $0.0040 * 27000 = $108
Bill amount that was fair: $612
Total Cost: $720

Beeing billed for nothing is not a nice thing…
But in your perspective is great…it will help to pay your salary.


In your example, are these based on actual numbers or just assumed? How many times are you seeing an error vs an actual map?


Its not an actual example, its just assumed. I’m elaborating possible real scenarios, because I’m going to track many flights a day, can’t give you a real number, but it could be around hundred(s), I can’t give you a real relation in percentage between “error vs an actual map”, but imagine in 200, 10 fails, or 5, it doensn’t matter. If I have to spend $108 or $20 for nothing, it is also unfair.

Can you say to me that your “attempt to make MapFlight/MapFlightEx return a non-200 response for more conditions that should have been detected as failures, making it easier for applications to distinguish.” will really help me reduce unnecessary requests to your system and consequently not being billed for nothing? If so, how?


I can’t accept beeing biled because of server errors, just for say.


If you have an indication of how often the server is returning an error, Im happy to look into some remedies. Without knowing what the frequency is, I dont have an answer. We do not currently have an SLA for use of the API.


Looks like you’re not a bit worried about this issue from your clients.
Firstly you didn’t helped me with some of the questions I’ve made, like you are ignoring my questions and point of view, and also ignoring suggestions I’ve proposed to you as alternatives of your concerns on abusive applications.
You are saying to me that you’ll be “happy to look into some remedies” only if I have indications of how often the server is returning error? Oh please! If you have a good designed product, you have for sure, statistics on that. You have, for sure, indications if your responses are returning correct/complete/any information, or returning error, and the amount in a period of time.

I’m trying to avoid being billed because of some problems I’ve mentioned. I don’t know the frequency because I’m not yet using the FlightXml API in production, but I have prevision on how many requests I’ll do to your server monthly. I have to simulate this kind of issues happening, of course. The math is simple as I’ve showed to you above.
You seem not worried about this fact, I understand. In your point of view, this kind of situations of unfair billings to your clients, It doesn’t matter, since you’ve receiving free money that way, helping to pay your salaries.

I’m still not knowing if your “attempt to make MapFlight/MapFlightEx return a non-200 response for more conditions that should have been detected as failures, making it easier for applications to distinguish.” will really help me reduce unnecessary requests to your system and consequently not being billed for nothing? If so, how? And when do you have prevision to implement that?

I hope other clients see this post and give also feedback on this.


Since I’m being ignored, waiting and waiting for a feedback and nothing till now (you could at least say to me: “we are discussing this issue internally and we’ll work on that issue, and we’ll give you a solution for that”, but not even that!), I’m trying to reach other FlightAware Staff that could help to solve this issue. By checking other FlightAware staff in this forum, I’ve found @dbaker, @mduell, @maxtribolet, @Stephenemaciolek, @conej730, that could possible understand me and bring this issue internally for discussion.
Please, someone understand my point of view, and also consider making modifications in your way of counting queries to bill or give me something that can solve this issue.
I’ve also proposed you some possible solutions to respond to your concerns on server stability against abusive applications, so you can consider.



I have sent you a private message to attempt to resolve this discrepancy.


Sorry for my late reply.

I had responded you In that way. Hope you can read and consider my points.



Still waiting for your feedback…


I kindly ask for your response @cbw. Please do not ignore my response.


Hi @cbw and all FlightAware staff and clients of FlightXML API.

So because I’ve received little support FlightAware staff nor from its top manager @cbw regarding this issue and received zero support from @cbw latest “attempt to resolve this discrepancy”, I have no other choice than to expose this situation in this forum. I don’t wanted this, but have no alternative.

First of all, I’m disappointed of being ignored and I’m tired of your inaction and lack of will to respond my questions raised in this post.

I’m seeing you (@cbw) are “happily” responding others tickets, being logged in, while still ignoring what I’ve posted, and my requests for a feedback.
I know you were a period of time in vacances, (Jessica, your colleague, told me in your Flightaware chat support) but I have to say I’m requesting feedback to the response of your “attempt to resolve this discrepancy” since 6th March.
I have to add that you are clearly avoiding some of my questions. Also, you don’t admit you have unfair billing policies. All of this makes me sad, and upset for all your attitude, since you’re the top manager of FlightAware, you should give good examples to your colleagues.
Is that so hard to admit that your billing policies regarding your FlightXML service are not fair, because you bill every request independently unknown errors (client perspective) like, server errors, or missing/incorrected data from your side (data that you should have)?
Is that so hard to make changes in this policy?
You should build transparent services, with transparent and fair policies, also with good documentation (because the status of your API documentation is average/poor actually, you must admit) . Many of my (and others) questions in your forum were regarding lack of clarity in your documentation.

I’m posting here what was your offer to mitigate the problem with a screenshot of our “private” messages, because, most of all, I don’t agree with your offer, even if firstly I said that I’ve accepted it in a compromise from your side that you would change your policies latter.

I have to say I was clear in my response, I’ve exposed that way we wanted to integrate our services with yours, I’ve added other questions that are important to proceed with our integration that you haven’t responded, you considered nothing (still waiting and hoping that any Flightaware staff could respond to my questions)

I really hope other flightaware staff could consider all this, since the inaction of @cbw.


Hi msousajit,

I have sent you a message responding to your questions posted here.