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.
Possible uses of FlightXML include:
Integrating FlightXML radar data with your existing flight operations software
Using FlightXML in mobile apps for flight status or notifications
Compiling flight activity logs and records in your own database
Creating a customized alerting system based on the current status of your fleet
Streamlining flight planning by showing common routes as cleared by air traffic control between two airports
Adding real flight data to your simulations
Showing flight tracks in Google Earth
Creating visualizations of traffic patterns
Adding live flight information to your company's website
FlightXML 3.0 is a major update to the previous functionality offered by version 2 and focuses on these major areas of improvement:
Making it easier for applications developers to obtain all of the data elements about a flight with fewer requests
Exposing more data fields that were not previously available
Improving usability by exposting values in alternate formats, such as timestamps in local time and alternate coding formats
Simplifying pricing and make it easier to estimate your monthly costs by using a subscription model with predictable pricing
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
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 Q3 2017.
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.
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
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
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.
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
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)
This allows FlightXML to be used in environments in which it is inconvenient or impossible to invoke
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
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 the third quarter of 2017.
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.