API Chain using IFTTT and AWS Services – Knattra 2018

We hosted a hackathon where the participants created an API chain using IFTTT, with an infrastructure based on some AWS services. Checkout the aftermovie!

Knattra – The Hackathon

Under the name Knattra, Jayway frequently hosts events for students that are curious about working life and Jayway in general. The November 2018 edition of Knattra was held in the form of a mini-hackathon, where the participants created creative chains of APIs; like a digital Rube Goldberg Machines.

The goal of the hackathon was to create the longest and most creative chain of different APIs. This was done based on IFTTT (IF This Then That), a framework that allows you to create “applets”. Applets are simply triggered actions based on conditional statements. IFTTT has support for many services such as Gmail, Spotify, Instagram etc, but also Webhooks (an HTTP callback).

All the teams began with an identical start-applet and end-applet: their API-chain was to be initiated by pushing a flic button, and it finished when accessing an API that activated the hitting of a gong. What APIs to call between the start-applet and end-applet was up to each team to decide, as long as it was public (without apiKey or OAuth). Additionally we had an accessible Raspberry Pi with some fun functionalities (camera, proximity sensor, LED morse code displayer etc).

The Architecture

It is quite easy to chain lots of different applets in IFTTT that trigger each other. The tricky part is keeping track of what the chain is doing and displaying this. To do this we built an architecture in AWS (Amazon Web Services), routing each API call through our own custom Lambda function. The Lambda function made the web request, instead of IFTTT making the web request. It also activated the next applet. By doing this we could monitor a specific chain, see how long it is, as well as display that which a HTTP request to an API might return. We displayed the response in our frontend, our Electron App. In this app we also showed the current length of the chain.

Custom Applet

A custom IFTTT applet
A simple custom IFTTT applet that is compatible with the Knattra architecture.

The simplest example of creating an applet that is compatible with our monitoring architecture can be seen in the picture above. The applet is triggered (this) by a web POST request to each teams personal Webhook API address, with a specified “event name”. The applets action (that) is a new web POST request to the Knattra API.

Step by step

Below is an abstract description of the different steps involved when an applet is triggered:

How API calls are made with IFTTT and AWS
Overview of what AWS services that are used when the IFTTT action is performed.
  1. When the participants designed applets, the action of the triggered applet was a Webhook web request to our Knattra API. In this web request they specified the url of the external API they wanted to access, and specified the details of the HTTP request to this external API.
  2. We hosted this Knattra API using AWS API Gateway, accessing our Lambda function.
  3. The Lambda function accessed the external API by performing the specified HTTP request.
  4. Since the length of the HTTP response varied and could be long, the response was saved to a S3 bucket.
  5. The Lambda function published to the Knattra SNS Topic. The message published included the details of the HTTP request, a signed link to the HTTP response on S3 and the current count of the length of the chain.
  6. Each group subscribed to the SNS (Simple Notification Service) Knattra Topic, and received an email notification for each new message that was published (filtered by the groups email).
  7. The Knattra SQS (Simple Queue Service) also subscribed to the SNS topic.
  8. The frontend to the entire system was the Electron App. This app collected the messages from the queue one at a time, displayed the HTTP response, as well as the current score of the chain. The app also removed the messages from the queue when they have been displayed.
  9. As soon as the Lambda function was published to the SNS topic, it made a web POST request to the teams personal Webhook API address, hosted by IFTTT. Depending on the “event name” of this POST request, a new IFTTT applet could be triggered, hence continuing the chain.

Accessing Raspberry Pi

Apart from external API’s, it was also possible to include a Raspberry Pi in the chain. The Lambda function routed these kind of Knattra API requests to a separate SNS, which was subscribed by a separate Raspberry SQS. The Raspberry was running the AWS SDK and picking one message at a time from the Raspberry SQS queue, performing the specified functions. Each function would also provide a response, which also was saved to the S3 bucket just like the API responses. Some of the functions available were:

  • A camera: a picture was taken, uploaded to S3, and a signed link to its location was returned.
  • A clapper: if the microphone picked up a loud clapping sound within a certain time frame, a gif was returned. If not, another gif was returned.
  • A proximity sensor: if an object appeared close enough to the sensor within a certain time frame, a gif was returned. If not, another gif was returned.
  • A LED morse code displayer: a SOS signal was displayed on a LED.

The gong was actually not connected with the Raspberry Pi, as it had already been developed for another purpose at the office. The gong was controlled with a different microcontroller, accessed by a separate API.

Using Built-in Applets in IFTTT

There are thousands of built-in applets in IFTTT ready to be used, which also could be added to the API chain, such as adding a song to a Spotify playlist when receiving an email with a specific header. The problem with including these kind of applets in the chain is that the Lambda function can impossibly follow them, since it doesn’t go via the Lambda function.

Using built-in IFTTT applets
The workflow when tracking the usage of a built-in applet.

We solved this by creating an extra applet that was triggered by the same thing as the chosen built-in applet, but whose action is to POST request the Knattra API. These kind of POST requests were handled differently by the Lambda function. They only published the message to the SNS/SQS so that the action would be visible in the chain (in the Electron app and email), instead of doing any web requests to external APIs or the Webhook API address.


The possibility of debugging proved quite difficult. Debugging by examining the email notifications was hard. Using the Electron App was slightly more user friendly, as some limited error descriptions were shown. However, there were some things that sometimes made it difficult to know what was actually happening.

  • Latencies in API responses
  • Latencies in the IFTTT service
  • The IFTTT abstraction layers
  • Multiple teams using the same SQS and accessing the same APIs at the same time

The Winning Team

The prize for the most creative chain went to team BB-8, consisting of Myky Tran, Richard Luong and Michael Truong. In the Electron App we were able to follow an API chain with a solid China-theme. By providing creative headers they told us a story of what travelling through China could be like. For example, we were shown the Chinese flag, pictures of specific Chinese food, a live tourist photo and we got to hear the rap song “Ni Hao” on Spotify. They won 1-day tickets to go to Øredev.

NB! To know when our next Knattra event is being held, keep an eye on jayway.com/events.

Hugo Hjerten

As a software engineer, Hugo pays a lot of attention to detail, and is adamant about well structured and maintainable code. His go-to language is Python. As a dataOps Engineer, Hugo is passionate about reducing the end-to-end cycle time of getting value from data. Combining good software and data engineering practices is an up and coming area that he stays on top of. As a project leader, Hugo is positive and motivating. Being a quick learner, he is excited about trying new areas.

Leave a Reply