FlightAware alerts API

AeroAPI alerting can be used to configure and receive real-time alerts on key flightevents. With customizable alerting offered by our alert endpoints, AeroAPI empowersusers to selectively pick various types of events/filters to alert on. By doing so,you can receive specially tailored alerts delivered to you for events such as flight planfiled, flight departure (out and off), flight arrival (on and in), and more!To get started with alerting, the **PUT /alerts/endpoint** endpoint must first be usedto set up the account-wide default URL that alerts will be delivered to. This step mustbe done before any alerts can be configured and will serve as the fallback URL that allalerts will be sent to for the account if a specific delivery URL is not designated on aparticular alert. If this is not performed before configuring alerts, then you willreceive a 400 error with an error message reminding you of this step when trying to interactwith the **POST /alerts** endpoint. Once a URL is set via the **PUT /alerts/endpoint** endpoint,then alerts can be configured using the **POST /alerts** endpoint. The **GET /alerts** endpointcan also be used to retrieve all currently configured alerts associated with your AeroAPI key.The **GET /alerts** endpoint will allow you to easily retrieve the id of any specific alerts ofinterest configured for the account which can let you use the **GET** **PUT** and **DELETE****/alerts/{id}** endpoints to retrieve, update, and delete specific alerts.When configuring an individual alert, the *target_url* field can be set to a URL that’sdifferent than the account-wide target endpoint set via the **PUT /alerts/endpoint**. Ifthe *target_url* field is set on an alert, then that specific alert will be delivered tothe specified *target_url* rather than the default account-wide one. If this field is notconfigured for the alert, then the alert will be delivered to the default account-wide endpoint.By setting this field, one can easily target different alerts to be received by different endpointswhich can be useful for configuring per-application alerts or sending alerts to an alternatedevelopment environment without having to adjust a production alert configuration.For each alert configured, one-to-many ‘events’ can be set for alert delivery. While mostevents will result in one alert delivery, both the *arrival* and the *departure* events canresult in multiple alerts delivered (referred to as bundled). The *departure* event bundles thedeparture (actual OFF the ground) alert, along with the flight plan filed alert and up to 5per-departure changes which can include alerts for significant departure delays of over30 minutes, gate changes, and airport delays. FlightAware Global customers willalso receive *Power on* and *Ready to taxi* alerts as part of the departure bundle. The *arrival* eventbundles the arrival (actual ON the ground) alert, along with up to 5 en-route changes (including delaysof over 30 minutes and excluding diversions) identified. FlightAware Global customers will also receive*taxi stop* times as part of the *arrival* bundle. Setting a bundled type and unbundled type for anOn/Off will only result in a single alert in the case where events may overlap.If there is a need to change the alert configurations, updating an alert using the **PUT /alerts/{id}**endpoint and a unique alert identifier (id) is preferred rather than creating an additional alert.By doing so, you can avoid duplicate alerts being delivered which could create unnecessary noiseif they are not of interest anymore.If at any point there is a need to delete an alert, the **DELETE alerts/{id}** endpoint can beleveraged to delete an alert so that it won’t be delivered anymore. As a reminder, specific alertIDs can be retrieved from the **GET /alerts** endpoint.