Webhooks and polling (and pizza)
When connecting different apps together, it is vital to understand the difference between webhooks and polling. Webhooks and polling are two different ways to convey information and data between apps, and how they work will have a big impact on what tasks you can do and how you do those tasks in your workflow.
❓ Webhooks vs Polling
You need to send data from App A to App B. To achieve this, you have two main options: send that data by getting App B to poll App A (polling), or by having App A send data to App B when something happens (webhooks). Which of these options you choose will have significant implications for how you workflow works, what your workflow can do.
Both polling and webhooks respond to an event, but each respond to a different type of event. Polling sends data in response to a external request i.e. App B asks App A “give me this data”. Webhooks on the other hand respond to an internal trigger inside of App A i.e. “Send this data to App B when this happens in App A”.
Let’s illustrate this difference a bit further with an analogy we can all understand: ordering a pizza.
🍕 Where’s my pizza?
Let’s say that you have made an order for pizza to be delivered to your home. You want get updates about the status of your order.
Option one is to constantly call the pizza shop and ask them “Hey, where is my pizza and has it arrived yet?”. This is the equivalent of polling: you (the person who wants the information) has to request the pizza company (the source of the information) at regular intervals about something you want to know (where is my pizza).
Option two would be for the pizza company to send you regular text messages updating you on the status of your pizza: you get a text when the order is received, when it is out of delivery, and when it has arrived at your address. This is the equivalent of a webhook: the pizza company sends updates to your mobile phone automatically without you having to ask them for that information. All they need is your phone number so they can send that information.
🤔 Which is the right option?
Whether you should use polling or a webhook comes down to a few factors. The most decisive factor is which option is or the two is actually available to you. Some apps will allow users to access data by polling or webhook, but this is quite rare. Apps tend to go with either polling or webhooks. So sometimes the choice as to what method you can use has been made for you by the developers of the app you want to connect to.
Generally speaking, webhooks are best when you need to get up to date information in real-time (or as close to real-time as possible). For example, if you want to do something as soon as someone makes an order on your website, the most efficient way for that connection to be made is via a webhook. When it comes to workflow automation, we’ve found that the vast majority of use cases require real-time information or updates and that webhooks would be the best choice.
The problem with polling is that it can be very wasteful for both the app requesting the information, and the app sending information. Going back to our pizza shop example, polling them for updates on your order consumes both your mobile phone minutes (because you have to constantly call them) and takes up their phone line (because you are constantly calling them). When you are calling them every 30 seconds (because you really want to know where your pizza is), you can see how taking a polling approach becomes incredibly wasteful for both parties.
😢 What if I have no choice?
Where polling is the only option, you to do quite a bit of additional work to allow your workflow to perform actions on the incoming data. You will firstly need to set the polling interval – this needs to be set so that it is frequent enough to pick up any major changes that might occur, whilst being not so frequent that you are wasting API calls or hitting a request limit.
You will also need to develop a way to only pass through the data that has not been already passed through. This is because polling may send back the same data as the previous request e.g. if the first request sent back the last 50 orders, and only 10 more orders were made since then, the next request will send the newest 10 orders + 40 orders sent in the previous request already. To handle this will require you to maintain some sort of state inside of your workflow so you can detect and mark orders that are sent each time as being unique or not. This could be, for example, a database where each order that gets processed is a row with a unique ID, and every time orders are sent through it checks the incoming data against this database and only sends through the orders that cannot already be found in the database. As you can see, working with polling when you actually need webhooks it not ideal or easy.
Webhooks and Polling in Workflow86
Workflow86 has components which can handle both webhooks and polling. Webhooks can be handled using the Webhook Import component, which allows you to trigger a workflow by exposing a URL for another app to send data to:
Polling can be achieved by combing the schedule start component with the API Request and Response component. The time interval set in the Schedule Start component (e.g. every 30 minutes) will trigger the request made in the API Request and Response component, and the response back will be parsed and then passed onto any further components. Each time the schedule start is run, it will consume a workflow session, so we recommend you be really careful with your frequency of polling using this method.
Sign up for free now 👇
To try out these features and more, create a free Workflow86 account now