All travelers want a smooth day of travel. There are several key features of the Alert API that a developer can use to improve the traveler's experience.
1) ruleId - The Alerts API allows you to create a ruleId to be notified only when something interesting happens for a particular flight. This means you do not have to continually look up the Flight Status. The Alerts API looks at the flight once a minute on your behalf. You can specify one flight per ruleId. You can monitor on one or more event types per ruleId. A ruleId consists of the flight details (carrier, flight number, departure date, departure airport, and arrival airport) and the events you are interested in:
You may receive zero to many callbacks on each ruleId:
2) Published schedules - Several FlightStats features are designed for flights that have a published flight schedule (example: add a flight alert). We update our flight schedules daily. Airlines have business relationships with major schedule providers. It is the responsibility of the airline to work with the schedule providers to make sure their flight schedules are up-to-date. Please see the Schedules API:
3) Configuration options - Please carefully review the available alert events. Depending on your business requirements, you will want to use some events and not others. Some travelers may be very concerned about departure delays and less concerned about arrival delays. Other travelers may want pre-departure alerts where a waiting limousine driver at the arrival airport only wants pre-arrival alerts. The configuration options that you choose will be dictated by a thorough understanding of your travelers' alerting needs. For best results, we recommend you create flight alerts no earlier than two weeks before scheduled gate departure because the flight schedule may change. Further, we recommend you create flight alerts no later than two hours prior to scheduled gate departure because some callbacks are not available during the flight. In addition, flight alerts may not be created for past flights.
4) Validating a flight - We will verify the existence of the flight requested if it's more than 36 hours in advance of the published departure. If it's less than 36 hours prior scheduled gate departure, we will find the best matched flight given either the departure or arrival airport and successfully create a flight rule in our system.
5) skipValidation - Skips the step of verifying the existence of the flight requested and obtaining the expected alerting capabilities for it. This can be used to force a rule to be registered for a flight that FlightStats does not currently have any knowledge about (a flight which is not in the published schedules or detected from operational information). Capabilities are not considered when validating rules.
6) testRun - Parses the request and checks the existence of the requested flight and the expected capabilities for alerting on it (unless "skipValidation" is also included, in which case only the request is validated). This can be used to verify flight alerting capabilities before deciding to register a rule. Do we typically have coverage? A perfectly configured flight alert may yield unexpected results if we have incomplete operational flight data coverage. The capabilities feature allows you to decide whether or not it makes sense to monitor a flight for which we typically do not have coverage. The rule returned does not contain a unique id, is not stored and will not be alerted on. More information on flight alert capabilities:
7) Simulated alert - Test your alert services with a simulated alert. We made this service to help you create and test your alert webservices, where FlightStats will send alert messages. When you invoke this service, FlightStats will send a simulated alert - a fake event for a fake flight - to your URL.
8) Test via email - For testing and evaluation purposes (no production use, please), we will also deliver alert data via email if the URL is of the form smtp://firstname.lastname@example.org.
9) Retrieve flight rule - You can look up a flight rule to compare it to what the traveler describes. (Example: Traveler states that the flight departure was delayed and that they did not receive a departure delay alert. You may look up the flight rule to verify that they were in fact monitoring for departure delays, that the traveler entered the correct flight details, etc.)
10) Deletes a previously registered rule by ID - You can add flight rules in some cases up to 300 days in advance of scheduled departure. You are not charged for flight rules that you delete prior to our system doing any work on the ruleId on your behalf (example: you will not be charged if you delete it before our system sends you any callbacks).
11) Can a delayed flight depart on-time? Can a canceled flight still operate as scheduled?
12) Optimization and scaling considerations - We recommend that you queue rule submissions, so that your system can tolerate temporary FlightStats outages or varying latency. In particular, we recommend that you do not invoke the Alerts API rule create feature on a user interface thread.
Likewise, we recommend that when an alert is posted to your end point, you queue the alert and process it asynchronously. If Flex cannot deliver alerts to your end point quickly enough (example: there is a slowdown on your inbound server), it may delete some of the undelivered alerts to prioritize timely alerts. Provided your queuing mechanism is efficient, you will never lose an alert and will be able to better monitor your alert backlog.
If you expect a large volume of alerts, let us know and we can fine tune the delivery characteristics (concurrency, timeout durations) for your account.
Article is closed for comments.