Removing Unused Alerts Based on changed Attribute

FlightAware AeroAPI
1

We run a transportation service around the airport, mainly dropping off and picking up passengers. We use the FlightAware AeroAPI to monitor flight information and set up alerts for events like landings, gate arrivals, and departures. We configure these alerts using the unique fa_flight_id, which is specific to each individual flight.

To manage and remove unused alerts, we currently use the changed attribute from the GET /alerts API response. We assume that the changed attribute, which shows the last time the alert was modified, is updated by FlightAware when significant events happen (like when a flight lands). Based on this, we run a SQL query to filter alerts where the changed timestamp is one week or older, and then we remove those alerts using the DELETE /alerts/{id} endpoint.

Here are my questions:

  1. Is the changed attribute the right field to use for identifying when an alert should be removed? Does it get updated by FlightAware when flight events occur, like landing or gate arrival?
  2. Is there a better or recommended way to safely remove unused alerts that will never be triggered again?
  3. Are there any best practices or standard methods for managing and cleaning up alerts in the FlightAware AeroAPI?
  4. Does FlightAware have any internal restrictions on the number of alerts that can be set up? We set up over a hundred alerts each day, and we want to make sure we’re managing these efficiently.

Thanks for any help and suggestions!

2

I’m pretty sure that alerts that have been configured against a specific fa_flight_id (and not a recurring ident) will automatically be deleted once the flight has completed.

We generally recommend specifying an end date for the alert that is on or after the arrival time of the flight–this will ensure that the alert is automatically deleted. It shouldn’t be necessary to explicitly DELETE alerts if you ensure that it has an end date specified.

I don’t think there is currently a specific limit on number of alerts for AeroAPI users at this time, although keep in mind that you are still charged per each alert that is delivered. However, abusive numbers of alerts that become a server-performance problem may require us to contact you.

If you are creating alerts in an automated manner, I strongly recommend ensuring that your service cannot ever create duplicate alerts for the same flight. (If you are creating alerts on behalf of your own users, you should try to combine requests from multiple users for the same flight into a single alert and perform your own fan-out delivery to those multiple users.)