All requests must include a username and FlightXML API Key
(don't have one?). In addition to
obtaining an API Key, the user's account must be specially enabled by a FlightAware representative for
access to the firehose service.
If you have a firewall that needs authorization, then please authorize both of the
CIDR network block
A customer's application will connect via a TCP socket secured with Secure Socket Layer/Transport Layer
Security (SSL/TLS) protocol version 1.2 or higher to FlightAware. The port for downlink connections will be 1501. The hostname
will be firehose.flightaware.com, unless FlightAware has instructed the customer otherwise.
On the downlink connection customer's application will send an initiation command followed by a newline
character, to specify the credentials, time range, and any filtering of messages to be provided, and
sides will keep the connection open indefinitely for FlightAware to send messages to the customer as
become available. If an error in the syntax or credentials of the initiation command occurs, the
server will transmit an error message and disconnect.
The customer's application should be designed to detect socket disconnection and attempt to reconnect to
the FlightAware server when necessary. It is also recommended to have an idle connection handler that
will disconnect and reconnect if no messages have been received in the last 5 minutes. When reconnecting
to the FlightAware server, the "pitr" or "range" initiation command can be used to resume playback from
the pitr timestamp of the last received message, if desired.
An important initial diagnostic technique is to confirm your
outbound network connectivity over the necessary port number. For testing and development purposes, the
OpenSSL command-line tools can be used to check the ability to open a SSL/TLS connection to FlightAware:
openssl s_client -host firehose.flightaware.com -port 1501 -tls1_2
If the connection is successfully established, OpenSSL will display the server's certificate information
and then pause. Should it fail to connect, contact your network administrator to ensure that your
application server has access to make outbound TCP connections on port 1501 to the FlightAware
Keeping a Persistent Connection
- Network connectivity for long-lived network connections over the internet are not always reliable
and will tend to stall or hang occasionally, beyond our control. Additionally, we can occasionally
have internal network connections that might disrupt communications between our Firehose server and
the internal messaging bus that might also cause this type of condition. Very long-lived Firehose
connections do eventually need to be disconnected by our server-side (system updates, feed
maintenance, resource leaks), but that condition should result in a "connection closed by peer"
rather than a "series of end of lines". Be sure that your application has logic to handle the
condition of the connection being actively closed by the server.
- Keeping a persistent connection open is the expected use-case. We also recommend disconnecting and
reconnecting if you receive no data after an extended period of time. When reconnecting, using the
"pitr" command to resume data from the timestamp that you last received is recommended.
- The maximum number of allowable connections for Firehose is three per user account. One connection
is suggested for your production environment and one connection for your development environment.
Additional connection licenses are available.