In this post, Paul explores the use of Zapier and similar services use of the FSA Food Alert API, as a way for pulling in data from the API as part of a workflow.
We recently met with a food tech service provider and learnt that they use the Food Standard Agency (FSA) Food Alerts API, that we built for the FSA, to keep up-to-date on food alerts and send their customers notifications when new alerts are issued. They mentioned that in order to monitor the API for new alerts they use Zapier.
Zapier, like IFTTT (If This Then That) , Make and other similar services, provide ways to create digital workflows by linking different digital services together, without the need for developing code. Most commonly the linking or ‘integration’ is between widely used services – some examples from the Zapier Website include:
- Send Slack messages whenever Google Sheets rows are updated
- Create Trello cards and Google Sheets rows for new starred emails on Gmail
- …
Zapier, like other similar systems, uses an interactive/forms-based User Interface to provide a ‘no-code’ approach based on a flexible ‘Trigger + Action’ flow. Where:
- A change in data, state or notifications in one service is used as a trigger to initiate a workflow
- Often data processing takes place, e.g. to parse and/or reformat data from the triggering service suitable for the next ‘action’ service
- An action is taken (optionally multiple options) in the ‘action’ service, e.g. to update a webpage, send a notification, update a secondary data source, etc.
Zapier describes it as ‘When X happens do Y then do Z’. Zapier calls these ‘Zaps’.
Zapier, IFTTT and Make all have a ‘freemium’ business models, with basic features such as, standard integrations, lower frequency triggering, fewer integrations, etc. being free and tiered paid for subscriptions that enable more flexible or specialist integrations, more frequent triggering, larger numbers of integrations, etc.
It is worth noting that integrations with other Apps/services often require giving the Zapier and the other automation services, access to data/permissions in those Apps, which is a security issue that needs consideration.
We thought we would take a look at what it would involve using the FSA Food Alerts API as the trigger to provide a bespoke action when a new Food Alert is issued by FSA. This blog briefly reports what we found.
FSA Food Alerts API
A quick recap of the FSA Food Alerts API – as outlined in previous blog posts, the FSA Food Alerts API provides an open and flexible means to query FSA’s data about food and feed alerts since early 2018.
FSA Food Alerts are the primary mechanism by which the public and others are alerted that food products are recalled because of allergen related or other issues. While users can sign up via the FSA website to be sent alerts by e-mail or SMS, the alerts information is also required and used by other organisations, for example allergy charities, such as Allergy UK and Anaphylaxis UK and other application developers including Mobile App developers and those wishing to monitor food alerts and recalls in support of the food industry.
The API provides queryable access to detailed information on the alerts, including types of alert, date ranges of issuing, types of reason for recalls, relevant allergens, etc. The data can be obtained in a variety of formats; HTML, CSV, JSON (the most widely used format for programmatic access to API data), RDF and TTL (formats widely used for linked data).
For more information see the FSA Food Alerts API documentation or our project page.
Using the Food Alerts Data with Zapier
Zapier has a wide range of integrations already available for commonly used digital service, and more flexible options for arbitrary services, such as the FSA Food Alerts API. It turned out that to use the more flexible integration Zapier’s Webhooks trigger requires a paid for subscription, similar seems to be the case for IFTTT. However, Zapier have a free trial of the Professional subscription and we used that trial for our experiments.
For our experiment, we used a very simple Zapier Webhook event & trigger called ‘Retrieve Poll’, i.e. poll a URL and look for new entries, in json format.
To keep things simple we will illustrate here using an API request that returns a list of the 10 most recent alerts in reverse modified (date-time) order, i.e. most recent first.
https://data.food.gov.uk/food-alerts/id?_sort=-modified&_limit=10 returns:
We could use a more complex/bespoke API query, e.g. only being triggered when a new Allergy Alert (AA) with an allergen of walnut is issued.
https://data.food.gov.uk/food-alerts/id?_sort=-modified&_limit=10&type=AA&problem.allergen=walnut 
Here we use the items key from the API and the nested modified property as the deduplication key. Which means that the Trigger happens when an alert is found with a new modified date-time. We Could have used the @id property, but using modified date-time has the benefit that if an alert is retrospectively edited the event will be triggered. That’s potentially useful because sometimes there are minor edits to a published alert that retrain the same @id value. However, where there are any significant edits a new update alert is created that has a new @id value. This trigger captures both cases. The trigger can be tested and data retrieved. This is then used in the next step to populate the Action step with relevant data.
Again to keep things simple we chose a basic Action – to send an e-mail to a specific e-mail address when the triggered event happens.
This was easy to set up, Zapier parses the json returned from the test of the trigger and provides a list of the relevant property keys to populate the title and body and other data fields (and attachments) of the email (e.g. see figure).
Once complete the Action can be tested and a test e-mail is sent. Here is the body of the e-mail received during the Action testing phase. However, as of today (12 Dec 2023) there have been no new food alerts issues, so we have not yet had a live notification to fully confirm our integration is working correctly.
Rather than sending an email, we could have chosen a different integration, e.g. to update a Google Sheet, or create a Slack message, etc. Although those latter integrations do require giving Zappier access to data/permissions in those Apps, which, as we say above, is a security issue that needs consideration.
Once that’s set up, the integration is ready to go. Zapier polls the URL and if there is a new value based on a specific json key and ‘deduplication’ value, the Action is Triggered. Which means that if a new json object is found in the response from the API (based on a new value to the specific key), then the action is triggered.
An additional setting is how often Zapier polls the URL (polling interval). Our trial ‘Professional’ subscription has a minimum of every 2 mins and a max of 15 mins. The ‘free’ and ‘starter’ subscriptions have a minimum of 15 mins. We choose 2 mins for our trial.
From a service provider’s perspective, it’s good to see that the polling is set to a minimum of every 2 mins, and 15 mins by default, so as to avoid flooding the API with requests.
Interestingly, looking at the Food Alerts API service server analytics, over about 5 days, in practice, the polling intervals from Zapier, on this query, appear to be a distribution with a mean of about 3.9 mins (max = 19 mins, min = 1.6 min) and median of about 2.3 mins.
Summary
Zapier and other similar workflow automation services, such as IFTTT (If This Then That) and Make, provide an easy way of querying the FSA Food Alerts API for new alerts that meet specific criteria and then triggering actions in other applications, such as e-mail, Slack, Google Sheets, social media platforms, website and blog platforms, etc.
Creating the trigger and actions was simple, documentation was generally helpful and testing mechanisms made it easy to experiment and refine the trigger and actions. We can see that it could easily be used to provide a simple-to-develop and adaptable mechanisms for integrating FSA Food Alerts data into other workflows and services.
It was interesting to see from the service provider end, that the Zapier polling frequency was variable although the mean and median durations were close to the expected value.
In the cases we looked at, the flexible ‘webhook’ mechanism required to create a bespoke query to an arbitrary API (like the FSA Food Alerts API) requires a paid subscription. We would want to look more into the security issues of providing the required access to other Apps/services such as Google, Slack, social media platforms, etc. before using them in a live/production system, but there are various ways of using the services without that deeper integration.