FlightXML3 Questions

FlightAware AeroAPI
1

Congrats on the V3 Beta! Love the new pricing model (I think). A few questions…

Correction

You’ve got old copy talking about V2 and V1 in the V3 FAQ - flightaware.com/commercial/flightxml/v3/faq.rvt - specifically the bit talking about “What are the plans for FlightXML 1 now that FlightXML 2 is available?”

Suggestion

It’d be dandy if IATA codes (as useless as they are) were available (as a field that’s returned; I know they’re not unique, so wouldn’t work as a parameter) via AirportInfo; many folks expect those over the ICAO codes.

Questions

Are faFlightID’s consistent between V2 and V3? If I get a push notification from V2, can I query V3 with faFlightID for details?

Is each call to the API or push notification (once they’re available) going to count as a single query insofar as your new pricing model is concerned? In other words, are there cases where a single API call could get charged for multiple queries (including include_ex_data with a call to FlightInfoStatus, or requesting 150 results from AirportBoards, etc.)?

What’s current best thinking for timeline on push notifications? Are we weeks, months, or years away? (Never mind - I see Q3 2017 is the target launch).

How are queries that exceed the per-minute rate limit handled? Do you queue them up on your end and return info as time allows? Return a 429 header? Return data and have sales get in touch with a recommended upgrade to the next plan?

2

We can look at returning the IATA code for the airport in AirportInfo. That shouldn’t be a big change.

FlightIDs are consistent, so if you get alerts that you setup in V2, that same FlightID can be used to query FlightXML3.

So for the counting of queries, we’re still considering 15 results to be a hit and multiples of 15 beyond that as another query. So if your query return 150 results we would count that as 10. FYI for AirportBoards, that divide by 15 logic will be applied to the result with the most queries. So if you call AirportBoards and Scheduled returns 100, but enroute return 50 then we use the 100 result to compute query cost (but we don’t hit you for each of those arrays, just the biggest one).

The updates for push notifications are probably a couple of months out, but you can continue to setup alerts on V2. The push notification that is sent out after your alert is setup does not count against your queries.

If you exceed the rate limit you’ll get a 429 response. We don’t cache them on our end.

3

Appreciate the quick response, thank you! The AirportBoards method will be particularly useful for the app I’m working on.

For the push notifications, should we expect a similar amount/type of data as we’re getting from V2, or are you reducing the amount of info getting pushed to encourage a query in exchange for not charging on a per-push basis?

4

I’m not sure yet what we’re planning regarding the content of flightxml alerts. I would guess that we will include some of the information being exposed in v3’s data, but it’s not certain yet. As we start working on it we can provide more updates at that point.

5

I’m seeing a 500 when I exceed the rate, is that expected or am I hitting some other limit? Here’s the response:


 data: 'Too many requests in a given amount of time.
',
  status: 500,
  statusText: 'Internal Server Error',
  headers:
   { server: 'nginx/1.12.1',
     date: 'Sun, 16 Jul 2017 19:44:45 GMT',
     'content-type': 'text/html;charset=utf-8',
     'content-length': '45',
     connection: 'close',
     'x-fa-user': 'REDACTED',
     'x-fa-userid': 'REDACTED',
     'access-control-allow-credentials': 'true',
     'access-control-allow-methods': 'POST, GET',
     'access-control-allow-origin': '*',
     'access-control-max-age': '1728000',
     vary: 'Accept-Encoding',
     'accept-ranges': 'bytes',
     'x-varnish': '348233592',
     age: '0',
     via: '1.1 varnish',
     'x-fa-cache': 'MISS',
     'cache-control': 'max-age=5, must-revalidate' },
  config:
   { transformRequest: { '0': [Function: transformResponseJSON] },
     transformResponse: { '0': [Function: transformResponseJSON] },
     headers:
      { Accept: 'application/json, text/plain, */*',
        'User-Agent': 'axios/0.9.1' },
     timeout: 0,
     xsrfCookieName: 'XSRF-TOKEN',
     xsrfHeaderName: 'X-XSRF-TOKEN',
     method: 'get',
     params: { ident: 'UAL390@1500073800' },
     auth:
      { username: 'REDACTED',
        password: 'REDACTED' },
     url: 'https://flightxml.flightaware.com/json/FlightXML3/FlightInfoStatus',
     withCredentials: undefined,
     data: undefined } }
6

Great work, having the IATA codes would be super handy for me too in the new API so hope that comes in soon.

7

It should be giving you a 429 when exceeding the message rate. I’ll have to check and see why you’re getting the 500 and put a bug in to fix that.

Regarding the IATA codes we’re looking at how we’re going to incorporate them and where we want to do that.

8

I just checked to see if anything has changed since I made that post weeks ago and yep, still getting 500s.

9

Hi John,
I know this is totally out of topic. :pray:
How do you use axios to make request in your JavaScript.
I always get 401 or only OPTIONS request is sent.

10

You’ll probably have trouble making the request directly through the browser (I’m not familiar with axios, but I’m assuming it is some sort of js framework) because at least chrome is blocking a request url with the credentials embedded in the url (ie https://username:password@flightxml.flightaware.com…) and because we don’t support CORS you can’t make the cross site authentication request. We recommend making the call in your backend so that you don’t expose your username and api key to the world.

At some point we may add the ability to restrict access for a key based on ip or referrer much in the same way that google maps API does, but that’s probably a ways down the road still.

So I’ve discovered that the version of apache we are running does not support the 429 status code, and while we are planning to upgrade it will not be in the very near future. As such we’re going to pick another response code for hitting the rate limit. I’ll get back with what that will be once we decide on that.

1 Like
11

I’ve moved requests to a nodejs app. Rarely the server responds with a {type=“Buffer”, data=[123, 134,55, …]}
Is it because of throttling.

12

No I don’t believe I know of a way that we can be sending that response. If you hit the cap you’ll get something like this in the body with a 500 status:
“Too many requests in a given amount of time.”