Using AeroAPI, programs can query the FlightAware live flight
information and recent history datasets.
Queries for in-flight aircraft return a set
of matching aircraft based on a combination of 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, among 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 flights' flight tracks can
be requested as well.
For airports, AeroAPI 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 AeroAPI include:
- Integrate AeroAPI radar data with your existing flight operations software.
- Use AeroAPI in mobile apps for flight status or notifications.
- Compile flight activity logs and records in your own database.
- Create a customized alerting system based on the current status of your fleet.
- Streamline flight planning by showing common routes as cleared by air traffic control between two airports.
- Add real flight data to your simulations.
- Show flight tracks in Google Earth.
- Create visualizations of traffic patterns.
- Add live flight information to your company's website.
To access AeroAPI 2, all requests must include a username and AeroAPI Key (don't have one?).
This data is transmitted via the "basic" HTTP Authentication standard, which is sent to the AeroAPI server as a part of each HTTP request.
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.
Web Services / SOAP / WSDL
The primary protocol recommended for use with AeroAPI 2 is the "Simple Object Access Protocol" (SOAP). Most modern SOAP implementations support use of "Web Services Description Language" (WSDL) definition file, which greatly simplifies accessing web services.
View: AeroAPI 2 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 AeroAPI 2 WSDL uses the "Document/Literal wrapped" method for encoding SOAP requests and responses.
This is a newer method that recent SOAP industry standards dictate should be used instead of the older
"RPC/Encoded" method that was used by the AeroAPI 1 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
To access any method, simply perform either a GET or POST request to http://flightxml.flightaware.com/json/FlightXML2/METHODNAME using 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
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.
To use pushed notifications, you must first call the "RegisterAlertEndpoint" method once to configure the URL endpoint where your server-based application can receive POST requests via HTTP or HTTPS. Once the URL endpoint has been registered, you can use the "SetAlert" method to define the triggering event conditions for the notifications that you want to receive.
When an event occurs, your URL endpoint will receive a POST request containing a JSON message. Although you can define alerts using either the SOAP/WSDL or REST/JSON interfaces, pushed notifications are always delivered in a JSON format. Delivery of each alert is attempted only once and is made on a best-effort policy. Your URL endpoint must accept the POST request and return a successful response within 5 seconds. It is recommended that your URL endpoint return a "Content-type" of "text/plain", and a short body (less than 32 characters) that acknowledges receipt of the pushed alert. If troubleshooting of alert delivery is required, the body responses for each delivered alert can be later reviewed on the Recently delivered alerts page. You can also use the AeroAPI Push Notification Testing Interface page to manually generate sample messages to be sent to your endpoint.
Show example (JSON push notification)...
"long_desc": "DAL116 arrived at KATL (Hartsfield-Jackson Intl) at 04:11PM EST from KTPA (Tampa Intl)",
"short_desc": "DAL116 arrived at KATL from KTPA",
"summary": "DAL116 arrived at KATL from KTPA",
"route": "ENDED4 CTY HONIE8",
"long_desc": "Delta #1752 (DC95) has just filed a flight plan. It is scheduled to depart from Jackson-Evers Intl (KJAN) at 01:05PM CST heading for Hartsfield-Jackson Intl (KATL) for an estimated arrival at 03:34PM EST.",
"short_desc": "DAL1752 (DC95) filed to depart KJAN @ 01:05PM CST for KATL @ ETA 03:34PM EST (MEI LGC3)",
"summary": "DAL1752 filed a flight plan KJAN -> KATL",
...rest of sample omitted for brevity...
"long_desc": "Delta #116 (B752) departed Detroit Metro Wayne Co (KDTW) at 06:44PM UTC enroute to KATL (Hartsfield-Jackson Intl) for an estimated arrival at 08:30PM UTC",
"short_desc": "DAL116 (B752) departed KDTW @ 06:44PM UTC for KATL ETA 08:30PM UTC",
"summary": "DAL116 has departed KDTW for KATL",
...rest of sample omitted for brevity...
The description of the JSON attributes are as follows:
- long_desc -- human-readable description of the event (sometimes longer than 80 characters). Not intended to be machine parsed, since this text is localized and the formatting is occasionally altered. (required)
- short_desc -- human-readable description of the event (generally about 50 characters long). Not intended to be machine parsed, since this text is localized and the formatting is occasionally altered. (required)
- summary -- human-readable summary of the event (generally about 20 characters long). Not intended to be machine parsed, since this text is localized and the formatting is occasionally altered. (required)
- eventcode -- Indicates the type of event that has triggered this notification. May have one of the following values: (required)
- filed -- details about an upcoming flight have been received (generally 1-2 hours before departure)
- departure -- flight has departed from the origin (runway wheels-up or gate block-off)
- arrival -- flight has arrived at destination (runway wheels-down or gate block-on)
- cancelled -- flight has been cancelled prior to departure.
- minutes_out -- flight is several minutes (usually 30-45 minutes) from its destination.
- diverted -- flight has been diverted to another airport. To retrieve the new flight details, call FlightInfoEx to access the new flight by faFlightID or ident.
- change -- some aspect of the flight plan has been modified, such as a departure time delay or a gate change.
- alert_id -- Integer identifier of the alert that triggered the event. This is the value returned by SetAlert, and can be used with DeleteAlert to stop receiving notifications. (required)
- flight -- Nested array with more details about the flight. Due to technical data limitations, some of these nested values (such as the actualarrivaltime and actualdeparturetime) may not yet be available for the latest event that is being alerted, but a subsequent call to FlightInfoEx might. Description of the nested values:
- ident -- Operating identifier or registration for the aircraft (required)
- aircrafttype -- Type of aircraft, if known (optional)
- origin -- Origin airport, if known (optional)
- destination -- Destination airport, if known (optional)
- filed_ete -- Scheduled flight duration, if known (optional)
- route -- Filed route waypoints, if known (optional)
- faFlightID -- Unique FlightAware identifier for the flight, which can be used for FlightInfoEx or other methods (required)
- filed_altitude -- Altitude of the flight plan, if known (optional)
- filed_airspeed_kts -- Airspeed of the flight plan, in knots if known (optional)
- filed_time -- Timestamp of when the flight plan was initially filed, in UNIX epoch seconds since 1970. (required)
- filed_departuretime -- Scheduled flight departure time from origin, in UNIX epoch seconds since 1970. (required)
- estimatedarrivaltime -- Estimated arrival time at destination, in UNIX epoch seconds since 1970. May be zero or absent if not known. (optional)
- actualarrivaltime -- Actual time of arrival at destination, in UNIX epoch seconds since 1970. May be zero or absent if the flight has not yet arrived or the time is not yet known. (optional)
- actualdeparturetime -- Actualtime of departure from origin, in UNIX epoch seconds since 1970. May be zero or absent if the flight has not yet departed or the time is not yet known. (optional)