Version 3.0 Beta

Authentication and Authorization

The API key supplied must be authorized for Version 3.0 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 AeroAPI services are also available over SSL by simply substituting "https" as the protocol for any flightxml.flightaware.com URLs.

SOAP / WSDL

Version 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: Version 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 AeroAPI 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 Version 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 AeroAPI 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

Version 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 AeroAPI 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/FlightXML3/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/FlightXML3/WeatherConditions?airport_code=KJFK&weather_date=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 Version 3.0 Beta.

Although AeroAPI 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 AeroAPI 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 AeroAPI requests at various parts of a flight, reducing your costs by avoiding unnecessary API requests during uneventful time periods.