Setting up alerts requires two mandatory phases:

1. Register a default account wide destination endpoint.
2. Register the flight specific alert rules.

Step 1: Get an API Key and Test Your Webhook/Endpoint

Before writing code, test everything using visual tools to confirm the pipeline works. After logging into your FlightAware account, retrieve your API Key from the developer portal: My AeroAPI --> Overview. Paste your API Key into the API Key field under the Authentication header. This can be found under the Documentation tab.

If you do not have a webhook, then you can create a temporary webhook URL at Webhook.Site or a webhook/account with Pipedream.

Once you've inserted your API Key and obtained your webhook/endpoint, then scroll to the put /alerts/endpoint. Input your webhook URL and try your call. You should return a 200 response status.

A '400 Bad Request' error means FlightAware’s servers received your request, but rejected the format or parameters inside it. If you are returning a 400 error ensure that you are not creating an alert (POST /alerts) before registering a default endpoint. AeroAPI requires an endpoint destination be set up before an alert can be created. Query the PUT /alerts/endpoint first.

For security reasons, we recommend using URLs that use https. If you have already created an alert without designating an endpoint, then you can use put /alerts/{id} to collectively add your target URL to your current alerts. If your endpoint was accepted, then you will receive a response status with a 200 code. If you receive a 400 code or an "unconnected" message, then your endpoint was not accepted. An error has occurred with your endpoint. Try editing your URL or using another one.

Step 2: Creating an Alert

You will use the post /alerts endpoint to create an alert. We recommend that you familiarize yourself with the schema as the incorrect format or parameters can result in a 400 error. When creating your alert, you will see the following example displayed:

{
 "ident": "string",
 "origin": "string",
 "destination": "string",
 "aircraft_type": "string",
 "start": "1970-01-01",
 "end": "1970-01-01",
 "max_weekly": 0,
 "eta": 0,
 "impending_arrival": [
   5,
   10,
   15
 ],
 "impending_departure": [
   5,
   10,
   15
 ],
 "events": {
   "arrival": false,
   "cancelled": false,
   "departure": false,
   "diverted": false,
   "filed": false,
   "out": false,
   "off": false,
   "on": false,
   "in": false,
   "hold_start": false,
   "hold_end": false
 },
 "target_url": "string"
}

By selecting 'Schema', you will see a description of each parameter available. An asterisk, *, denotes that the field is optional. You can leave it blank or choose to delete it.

Go back to the 'Example' screen to input your parameters. The following are some things to pay attention to while creating your alert.

• We recommend creating your alert 1-2 days prior to when you want to begin receiving alerts. An end date is not necessary, AeroAPI will automatically begin monitoring immediately and keep running until you manually delete the alert (start and end fields can be omitted).

• Max Weekly: this is the maximum number of alerts you want to receive. The less defined the parameters are, then the higher the max weekly number will be. Your max weekly number should reflect this. If the number is too small, then you will receive an error message stating so. Simply increase the number or add more parameters. By default, the max weekly is set to 1,000 for Standard subscriptions and 4,000 for Premium subscriptions.

  

• ETA and Impending Arrival are the same thing. You can only set one at a time. If both fields have a value, then you will receive an error message informing you to fix the error.
• Alert settings can be set in 5 minute increments, i.e. 5, 10, 15, 20, etc.
• Adding true next to inflight events will notify you when the specified event has occurred.
• Don't forget to add your target URL at the end of your alert. put /alerts/{id} only works for alerts that have already been created.
• Creating the exact same alert configuration repeatedly, more than 50 times for the same flight/criteria, causes AeroAPI to block further creation calls with a 400 error to prevent system spam. We recommend using GET /alerts to view your current list of alerts or DELETE /alerts/{id} before running your script again.

When finished, your alert should look like the following:

{
  "ident": null,
  "ident_icao": null,
  "ident_iata": null,
  "origin": "KATL",
  "origin_icao": "KATL",
  "origin_iata": "ATL",
  "origin_lid": "ATL",
  "destination": "KJFK",
  "destination_icao": "KJFK",
  "destination_iata": "JFK",
  "destination_lid": "JFK",
  "aircraft_type": "A320",
  "created": "2025-07-09T20:55:00Z",
  "changed": "2025-07-10T13:55:03Z",
  "start": "2025-07-11",
  "end": null,
  "user_ident": null,
  "impending_arrival": [
    30
  ],
  "impending_departure": [
    5
  ],
  "events": {
    "arrival": true,
    "cancelled": false,
    "departure": true,
    "diverted": false,
    "filed": false,
    "out": false,
    "in": false,
    "off": true,
    "on": true,
    "hold_start": false,
    "hold_end": false
  },
  "target_url": "https://sites.google.com/view/apitestalert"
}

Step 3: Try your alert

A successfully created alert will display a status code of 200.

If an error was detected, then you will receive a status code of 400 followed by the reason it was not accepted.

If you receive the response mentioned above, then verify that there isn't a syntax error like a missing double quote, trailing comma, incorrect bracket, unsupported/conflicting fields in your payload. When testing via API UI portals Postman, the UI automatically fills optional payload fields with placeholder values like "start": "1970-01-01" or "eta": 0. AeroAPI tries to parse "1970-01-01" as a live time or "eta" and "impending\_arrival" simultaneously, failing validation and throwing 400 "alert JSON does not appear valid". We recommend deleting any optional fields you aren't actively configuring to keep the JSON request body minimal, see example below.

{
"ident": "DAL70",
"origin": "KATL",
"destination": "EHAM",
"max\_weekly": 1000,
"events": {
"departure": true,
"arrival": true,
 "cancelled": true,
"diverted": true
},
 "target\_url": "https://yourURL.net"
;}

Remember that you can use Notifications to check the status of recently delivered alerts and Flight XML to generate test messages.

_____________________________________________________________________________________________________________________________