FlightXML 3


About

The FlightXML API is an innovative web service that allows customers to design their own applications that leverage the extensive aviation data offered by FlightAware. Applications can access and respond to information about current, upcoming, and recently completed flights.

Queries for in-flight aircraft return a set of matching aircraft based on a combination of parameters, like location, flight or tail number, origin and/or destination airport, aircraft type, and/or a low-to-high range of altitude and/or ground speed, plus others. For each matching aircraft, data returned includes the flight or tail number, the aircraft type, origin and destination, time the last position was received, and the longitude, latitude, groundspeed, and altitude of that position. Matching flight tracks can also be requested.

For airports, FlightXML queries can return a list of scheduled flights, flights that have departed, flights that are enroute to the airport, and flights that have arrived at the airport.

Typical Uses

Possible uses of FlightXML include:

What's new in Version 3

FlightXML 3.0 is a major update to the previous functionality offered by version 2 and focuses on these major areas of improvement:

FlightXML 3.0 is currently available for "Beta" testing by customers interested in getting a sneak peek at our upcoming API release and helping us by providing early feedback. During the beta period, only a portion of our planned functionality will be available for access. In particular, pushed notifications and geospatial (birdseye) queries are not currently available during the initial beta testing period but are expected to be offered closer to the official production launch date.

Additionally, since some aspects of the FlightXML 3.0 API are not yet finalized, some aspects of the service should be expected to change between now and the official production launch. This may require modifications to any applications designed against the beta version of the API. The time period for official production launch of FlightXML 3.0 is 2018.

Legacy users of FlightXML 1 and FlightXML 2 will continue to be able to access those versions of the API without any changes to their applications. Each version of FlightXML uses a different endpoint URL which ensures that versions of the APIs are accessed independently. However, current users of FlightXML 1 are strongly encouraged to upgrade to FlightXML 3 in the near future, since that service will be discontinued on December 31, 2017. FlightXML 2 service will be remain available until at least December 31, 2018, but current users are also encouraged to upgrade to FlightXML 3 as soon as possible.

Pricing

Previous versions of FlightXML used a usage-based pricing model that billed users a small amount for every request made, with the price determined by the pricing class of the specific function accessed, and a discount based upon the total number of requests made per month. Many users found this pricing model difficult to estimate how much their monthly bills would be in advance, especially when designing a new application or when application usage might grow over time.

To make pricing easier to estimate, FlightXML 3 uses a monthly "tiered subscription" model that allows you to simply choose the features that most closely correspond to the functionality needed by your application. This simplifies budgeting and allows you to know that your monthly costs will be the flat subscription price that you had originally selected. (Maximum usage caps per month and request rate limits do apply to most of the tiers. Auto-upgrade to the next tier upon reaching your monthly usage limit can optionally be enabled.)

Additionally, to make it easier for new application developers to begin accessing FlightXML 3, a free tier is available with a limited number of queries every month.

View: FlightXML 3.0 Pricing

Authentication and Authorization

To access FlightXML 3.0, all requests must include a username and FlightXML Key (don't have one?). This data is transmitted via the "basic" HTTP Authentication standard, which is sent to the FlightXML server as a part of each HTTP request.

The API key supplied must be authorized for FlightXML 3 at the time it is generated.

The web service libraries available in most programming languages allow you to directly specify a username and password as an argument for the request, so that the authentication is transparent to your application as it makes requests. However, with some libraries it may be necessary to manually encode the "user:key" in base64 and send the result in the "Authorization" header as part of each HTTP request.

If data security is a concern, all FlightXML services are also available over SSL by simply substituting "https" as the protocol for any flightxml.flightaware.com URLs.

SOAP / WSDL

FlightXML 3.0 can be accessed using the "Simple Object Access Protocol" (SOAP) protocol. Most modern SOAP implementations support the use of a "Web Services Description Language" (WSDL) definition file, which greatly simplifies accessing web services.

View: FlightXML 3.0 WSDL XML

Although you can read the WSDL and generate SOAP queries manually, it is recommended that you develop your applications using a SOAP library that automatically parses the WSDL and populates your application namespace with the FlightXML functions.

It is strongly suggested that you ensure that your applications cache the WSDL file so that it is not necessary to fetch and parse the WSDL for every request or instance of your application. This will vastly improve the performance and efficiency of your application.

The FlightXML 3.0 WSDL uses the "Document/Literal wrapped" method for encoding SOAP requests and responses. This is a method that recent SOAP industry standards dictate should be used instead of the older "RPC/Encoded" method that was used by the FlightXML 1.0 WSDL. Most modern SOAP client libraries fully support this newer method, although some older SOAP libraries are not yet compatible. The SOAP client libraries listed in the examples section have been tested to be compatible.

REST / JSON

FlightXML 3.0 can also be accessed using a light-weight "Representational state transfer" (REST) inspired protocol that returns its responses encoded in "JavaScript Object Notation" (JSON) format. This allows FlightXML to be used in environments in which it is inconvenient or impossible to invoke SOAP services, such as mobile phone applications, web browser applications, or server-side JavaScript environments.

To access any method, simply perform either a GET or POST request to http://flightxml.flightaware.com/json/FlightXML2/METHODNAME using a standard CGI-style representation of the arguments. All requests made must supply the username and API Key as a "basic" Authorization HTTP header.

For example, the following URL is how you might request the current weather at John F. Kennedy airport (KJFK) in New York: http://flightxml.flightaware.com/json/FlightXML2/MetarEx?airport=KJFK&startTime=0&howMany=1&offset=0

Requests can be returned in "JSONP" format, allowing a web page to load the response in a way that avoids the same-domain security restrictions enforced by some browsers. To do this, simply specify the optional argument "jsonp_callback" with a value that is the name of the JavaScript function that should be invoked with the JSON data.

Pushed Notifications

This functionality is not available during the initial availability of FlightXML 3 Beta, but is expected to be made available prior to the go-live date of the full version in 2018.

Although FlightXML functionality is primarily intended to be accessed through a "pull" oriented request model using the SOAP/WSDL or REST/JSON interfaces, you can also opt to receive a "pushed" notification from our server to yours whenever certain flight events occur. Upon receiving a notification, your server-based application is sent basic information about the flight, its current status, and the triggering event. In response, your server-based application can initiate requests to FlightXML using the normal SOAP/WSDL or REST/JSON interfaces to obtain additional details. This can allow your application to intelligently reduce or increase the rate at which it makes other FlightXML requests at various parts of a flight, reducing your costs by avoiding unnecessary API requests during uneventful time periods.