The FlightXML3 Beta is now open. To use the new service you will need to subscribe to one of the 5 plans available. The details of the plans can be found on the Pricing Page. Included in the FlightXML3 plans is a starter option which is free and allows 500 queries per month and does not require a credit card. If you happen to have a PiAware or FlightFeeder that is active then you will get another 500 free queries per month at the starter level (total of 1000).
Documentation for FlightXML3 can be found on the FlightXML3 Documentation Page. On that page you will find general information on FlightXML3 usage. The API Reference page has details on all the method calls and their input parameters and return types. We have also posted examples and a FAQ.
We have a public github repository with example code for a variety of languages making both SOAP and REST calls.
The beta currently contains a subset of the methods that will be included in the production release. Details on additional methods will be announced here on the forums as they are made available.
If you have any issues or questions regarding the beta you can post those questions on the forums or contact support.
If you do sign up for the FlightXML3 Beta, we’d love to hear what you think about it and appreciate any suggestions to improve future releases. Please take a few minutes to fill out our FlightXML3 Beta user survey.
tl;dr The new FlightXML3 pricing is a barrier of entry for small organizations.
Push notifications are $0.0079 under FlightXML2, but are now a minimum of $124/mo under FlightXML3. How would you suggest developers working in a small organization justify the cost increase?
The FlightXML3 plans work for large organizations, but do not work for small organizations and completely prices them out of the market.
Just for my edification, was there really so much push back against a per-query model that warranted a monthly subscription model?
Hi Northeastern,
To answer your question, yes, we got a lot of feedback from our customers that price certainty was a major driver for them. We achieve that with the tiered model and the no-auto-upgrade option, allowing them to know exactly how much they will pay, per month, without question. It protects against mistakes in development and testing that cause runaway requests that aren’t quickly caught, and gives overall piece of mind with respect to predictability.
We don’t believe that the cost of monthly plans that include notifications are cost prohibitive. We think that there is a lot of value in timely notifications and that end users are willing to spend a little extra on a product to realize that value.
Respectfully,
Chadd
We’re not opposed to a tiered model for usage and it certainly makes sense to reserve some features (SLA, Support, OAuth, Multiple API Keys) for higher-end tiers. However, eliminating features such as push notifications and airport data from lower-end tiers seems a bit fiendish.
Operators our size and developers just getting into FlightXML will [most likely] never spend $500/month to receive airport data or $125/month for push notifications. I can’t help but presume that these new plans, in their current form, will stifle innovation and hamper the adoption of FlightXML.
Well it’s definitely in beta so there is always the chance that we make a breaking change before going into full production. However we’re trying not to do that and we will announce on the forums if we do make a breaking change.
Is there an eta when the push notifications will be available in the beta? And what will get send? Is it possible to get the gate time / a push notifications for the arrival at the gate?
With V2, using a query such as SearchBirdseyeInFlight, you could specify a list of types to filter by.
Is it possible to implement that with AirportBoards in V3? Or have you solved the issue with the heavy designation not working 100% of the time (see link below for reference)? If so, is there a way to tell it to only show me heavies? Is this in the filter input? If so, can you provide some documentation for that?
Also, what about specifying multiple types on the query, for example enroute and arrivals, but not departures or scheduled?
Also, is there a reason every single flight has the date, time, DOW, etc? Seems like extraneous data that could be omitted for faster delivery. All of that information can be derived from the epoch time, plus someone may not use the date in that particular format, for example. This information is helpful for query building because you need to decode the epoch time, but I think it should be a feature you can turn on or off and not on all the time.
I apologize for the late response. With AirportBoards in XML3 , you can have it select either arrivals, departures, en route, scheduled or all. It does default to all. We don’t have anything yet in XML3 where you can filter to have enroute and arrivals or filter out heavies like in XML2. I will look into if we have any plans to implement a feature to remove those extra times besides the epoch that you might not need.
To achieve what we have with V2 today, I would have to query a LOT more flights and filter it on the client side. As it is, with departures, I query 400 from the scheduled query and filter by the heavy types on the client side in order to get a decent amount of heavy departures into the near future.
As with the extra time info, it seems like this would reduce the amount of data you’re sending across unnecessarily.
FlightXML3 beta should still be considered an incomplete representation of what functionality will be available when it is complete. The equivalents to the v2 Search/SearchBirdseye functions are not yet available in v3, so if you require that functionality then you should continue to use FlightXML2 for your needs at this time.
Thank you. I do realize that this is a beta release, however, isn’t that the point of this thread? To get ideas for improved functionality, or am I missing something?
What is the lifecycle of each version? Do you still have clients using V1 today? If so, what is the EOL date on that?
Hi Guys,
Today I have recognized an issue with FlightXML 3. I have received the following errors:
Either atc_ident or airline_iata is invalid element (org.xml.sax.SAXException: Invalid element in com.flightaware.flightxml.soap.FlightXML3.FlightInfoStatusStruct - atc_ident). The implementation worked fine till today (or maybe during the weekend happened something.
Can anyone check it why?
I have called like this:
FlightInfoStatusRequest request = new FlightInfoStatusRequest( flightChain.getAircraft().getRegnum(), false, null, 1, 0 );
FlightInfoStatusStruct result = soap.flightInfoStatus( request ).getFlightInfoStatusResult().getFlights( 0 );
GetFlightTrackRequest r = new GetFlightTrackRequest( result.getFaFlightID(), false );
TrackStruct[] res = soap.getFlightTrack( r ).getGetFlightTrackResult();
