Unit introduction
Welcome to the final unit of the “What are Webhooks?” course!
By now you should have a good idea of what webhooks are, how they work, and how to send requests to them.
In this last unit you will learn more about:
- how webhook scenarios are triggered
- different types of triggers
- scheduling configurations
- webhook queue
Let’s begin!
Scenario configuration
You have seen that while building your scenario you can execute it by clicking the Run once button.
Once the scenario is ready, you wouldn’t want to have to manually start it, but you want it to automatically execute.
Imagine that executing your scenario is like cleaning your house: you don’t want to go and clean it yourself, but you have Clara the cleaner from the Another one wipes the dust cleaning company to do the work for you.
To set your scenario to run automatically, the first thing that you have to do is configure the Schedule settings. In the next page you will learn in more details about the different settings that you can choose.
When configuring the schedule settings, you’ll find various options for how your scenario can run:
- At regular intervals (e.g., Every 15 minutes)
- Once
- Every day
- Days of the week
- Days of the month
- Specified dates
- On demand
Notice that there are different options that you can choose to schedule your scenario. You will learn about them in this unit!
Then turn your scenario ON.
Now your scenario is active and ready to be executed.
Scenario setting
There are three different ways to configure the way your scenario starts.
Scheduled
What: You want to run your scenario at specific times, like every working day at noon, or every other Tuesday, or every 15 minutes.
Why: You need to back up your data at regular intervals.
How: Specify exactly when you want your scenario to run from the Schedule settings. Options include “At regular intervals”, “Once”, “Every day”, “Days of the week”, “Days of the month”, and “Specified dates”.
Note: A scheduled scenario will have the clock icon on the first module.
It is like having Clara the cleaner coming to your house every Friday at 10:30am.
Immediate
What: You want to run your scenario immediately, as soon as the data arrives or an event happens (e.g., a form submission).
Why: You want to immediately send an email to the warehouse team as soon as an order is placed on your online shop.
How: You can execute your scenario as soon as data arrives by selecting Immediately in the Schedule settings. You can also set a maximum number of runs to start per minute (between 1 and 10000) to avoid rate limit errors.
Note: A scenario configured to start immediately will have the lightning bolt icon on the first module. Only scenarios starting with webhooks can be configured to start immediately.
It is like calling Clara the cleaner immediately after you spill coffee on the table for her to clean it.
On demand
What: You want to manually trigger a scenario whenever you need it.
Why: You want to generate a specific report whenever it is needed, and not on a set schedule.
How: This is achieved using the Make API that allows you to execute a scenario. Select On Demand from the Schedule settings. You can also click Run once anytime you need the scenario to run.
Note: A scenario configured to start On demand will have the arrow icon on the first module.
It is like booking a one-time deep cleaning session with Clara the cleaner when you decide it’s necessary.
Pro-tip You can also use the Make app and the Run a Scenario module to start your on-demand scenario. You will learn more about this in the Make API unit of Make Advanced learning path.
Triggers
What is a trigger? If you look for the definition, you’ll find that in workflow automation, a trigger refers to the mechanism that starts a sequence of actions or workflows based on predefined events or conditions, whether those events are detected instantly or periodically checked at defined intervals.
They are events or requests that prompt Clara to start cleaning your house.
In Make, you can either use instant or polling triggers. Let’s have a look at them and later you will learn how they are related to the scenario configurations.
Instant Triggers
Instant triggers receive a notification as soon as an event happens. You will see later that according to the scenario settings the request can be either immediately processed or sent to the queue.
It is like informing Clara every time there is anything that needs cleaning in the house. For example, you break a plate and you send her a text and let her know that it will need to be cleaned up. Depending on your agreement with her, she will either come to your house immediately to clean it or make a note of it and let you know she has received the message.
Instant triggers use webhooks. In Make you can find both custom webhooks, which you’ve explored in these units, and predefined webhooks designed for specific Make apps. As you’ve seen in unit 1, modules that contain a webhook are marked with the instant tag and you will be able to easily identify them. An example is the Watch Changes module for Google Sheet, which has the INSTANT tag.
Polling Triggers
Polling triggers go and fetch new data. They allow Make to check if there is new or updated data in the external application. They can detect when there is new information to process since the last time they checked and they will go and fetch the new data since the last activation.
It is like Clara the cleaner who comes to your house once or twice a week to check on your whiteboard of cleaning tasks if there is something that needs cleaning.
Combinations
What happens when the triggers are combined with the different scenario configurations?
Instant Trigger
Scheduled scenario
Make immediately acknowledges the request when it happens. The scenario is not executed and the relevant information is saved in the webhook queue. When the scenario is started on a schedule, the data is retrieved from the webhook queue.
Every time something needs cleaning in the house, you send a text to Clara and she writes it down on her cleaning to-do list. Every Friday morning, when she comes to your house to clean it, she goes and checks her to-do list to see what needs cleaning.
Note: Schedule settings allow you to configure how often a scenario runs. Options include:
- At regular intervals
- Once
- Every day
- Days of the week
- Days of the month
- Specified dates
- On demand
Immediate scenario
Make immediately acknowledges the event when it happens. The scenario is executed straight away with the data that is received together with the request.
You spill something and immediately text Clara who comes straight away to clean it up.
On demand scenario
Make immediately acknowledges the event when it happens. The scenario is not triggered and the relevant information is saved in the webhook queue. The on demand scenario works like a scheduled one, with the difference that you decide when to run it. Instead of following a schedule. When you execute it using the Make API or clicking Run Once, the data is retrieved from the webhook queue.
Every time something needs cleaning in the house, you text Clara and she writes it down on her cleaning to-do list. When you realize that your house needs cleaning, you tell Clara to pass by and she checks her to-do list to see what she needs to clean.
Polling Trigger
Scheduled scenario
When the scenario is started on a schedule, the new data is fetched from the specific application that Make is querying.
You take a note on a whiteboard of all the mess in your house that Clara will need to clean up. Clara comes to clean your house every Friday morning. When she gets there, she asks you for all the new tasks, does them, and marks those already done.
Immediate scenario
Scenarios can’t be configured to Immediate when using a polling trigger. You can see that the Immediate option is not present in the Schedule settings when a polling trigger is used.
When something needs cleaning in your house, you write it on your whiteboard. You don’t notify Clara, so she doesn’t know that there is something that needs cleaning and your house remains a mess. This combination is not working and is thus not available.
On demand scenario
The polling trigger goes and checks the application for updates when the scenario is executed. The scenario behaves like a scheduled one, but you decide when to execute it using the Make API. When you do it, the new data is fetched from the specific application that Make is querying.
You take note on your whiteboard of all the mess you’re making in your house that Clara will need to clean up. When it is time for a deep cleaning, you call Clara. When she gets there, she asks you for the list of things that need to be cleaned.
Webhook queue
You have been hearing quite a lot about the webhook queue, let’s have a look at what it is.
As mentioned previously, it is like the to-do list that Clara uses to note all the things that she needs to clean when she is notified but doesn’t go to the house immediately.
The same happens with the webhooks.
A request to the webhook URL is stored in the webhook queue in these cases:
- the scenario is inactive (set to OFF)
- sequential processing is enabled in the scenario settings
- or the scenario failed under specific conditions
You will learn more about this in the Advanced webhooks course.
Note: Sequential processing means that the requests are processed one after the other.
Webhook queue info
After discovering webhook queues, you must have a lot of questions about them. Let’s answer all of them.
How do I access the queue?
There are two ways you can access the queue of a specific webhook:
Method 1 From the webhook scenario, right-click on the Custom Webhook module that has been used to create the webhook. Then select Show queue. This will take you immediately to the queue of that webhook. This method applies to all the modules containing webhooks, both custom ones and any other instant modules.
Method 2 From the side menu in Make, click Webhooks to access the Webhooks menu. This will take you to the summary page of all your available webhooks. Each webhook has a queue icon that displays the number of elements present in the queue. Click it to view the queue of that specific webhook.
How many items can be present in the queue?
There is a limit on the number of items that you can have in your webhook queue and it depends on your subscription plan. Check your plan to see how many items you can have in your queue.
Note: The number will differ from the one you can see on the screen, depending on your plan.
Which information is stored in the queue?
When you open the webhook queue you will see a table like the one in the picture, containing the ID, type, creation date and size of the item. You can delete it, or have a look at the details.
Parsed Items
In the Details section you can see the data that has been passed when the request has been made. In this case, you can see the JSON document contained in the body of the request. If your requests has query parameters, or the Get request headers setting is set to Yes, you will find query parameters and headers in the parsed items as well.
When do requests go to the queue?
Requests go to the queue in the following cases:
- The scenario is OFF and the request cannot be immediately processed.
- The webhook scenario has default processing settings (parallel processing), but a high number of requests arrives at the same time, and they cannot all be processed all together. Each plan has a different limit, but requests that do exceed it will go in the queue.
- Sequential processing is selected.
- The webhook scenario without webhook response and with default settings throws an error. The scenario is immediately stopped and the request goes in the queue.
Note: In the Advanced Webhooks course you will learn more about the webhook queue and see how it relates to different requests sent at the same time and different processing configurations. In this course you will also learn more about the behavior of webhook scenarios when errors and error handlers are present.
How are the items in the queue processed after activating the scenario?
The scenario is active (ON) and the data stored in the queue is processed only when the scenario executes, whether on demand or scheduled. For immediate scenarios you will have to manually inspect and re-run the requests in the queue.
The scenario is inactive (OFF) and the webhook has received and stored messages:
- If you click Run Once, you will be asked whether you want to process the data already in the queue, or if you want to wait for new data. If you wait for new data, the existing data remains in the queue, waiting to be processed.
- If you activate the scenario (ON), Make will ask you whether to delete old data in the queue or to process it.
What happens to the queue if the webhook is turned off?
As you’ve seen previously, every webhook has an ON/OFF button, independent from the scenario.
To be able to listen to requests, you have to turn the webhook ON. Then according to the scenario configuration, the data is either processed immediately, or stored in the queue.
In case the webhook is OFF, the webhook is not listening to any requests and the data sent won’t be stored in the webhook queue.
In this case, when you send a request, you will get 400 Bad request with a message saying Webhook temporarily disabled.
Time to practice
Now that you know more about the different triggers, the scenario configurations and the webhook queue, it is time to practice by building an easy scenario that will help you get a better understanding of these concepts by seeing them in action.
Scenario: Instant Spreadsheet Update
The cleaning company Another one wipes the dust has a spreadsheet in which they save all the items that they need to clean when they receive a cleaning request. Remember Clara the cleaner? Every time you need a room to be cleaned, you send her a text message with the items that need cleaning and she sends a request to update the spreadsheet with the required information. She wants to automate this process in a way that as soon as a request is received, a scenario updates the spreadsheet. Clara’s specific need is:
I want to instantly add the information I receive in a Google spreadsheet.
Let’s go help her building this!
Scenario: Scheduled Whiteboard to To-Do List Sync
Another scenario for practice is:
Every two hours, I want to retrieve all new requests my customer has added to their whiteboard and add them to my to do list.
Scenario overview
The scenario includes a Custom webhook module (instant trigger) and is set to run immediately. As soon as the request reaches the webhook, the scenario will process the information contained in the request straight away.
The scenario has two modules:
Webhooks → Custom webhook
This module is used to configure the webhook that will be associated with the scenario. The scenario is scheduled to run immediately.
The requests are sent to the webhook URL and the data is processed by the scenario as soon as it receives it.
Google Sheets → Add a Row
This module takes the information sent by the requests and uses it to update the spreadsheet.
Note: The scenario is immediately triggered as soon as the data arrives (lightning bolt icon). In this case Clara reads all her messages immediately and adds them to her spreadsheet.
Before you begin
Before starting, let’s prepare the spreadsheet that will be used by the scenario to store all the data.
Go to your Google Drive and create a new Google Sheet. Call it MI_C04_U04.
The scenario will save the data sent by the request to this sheet.
In cell A1 of your spreadsheet, enter ID. In cell B1, enter To_Clean to rename the columns.
Building it
Time to build the scenario. Work through each stage before you continue.
Let’s start building the scenario. Go to Make and create a new scenario. Call it MI_C04_U04.
Add a Webhooks > Custom webhook module to create the webhook linked to this scenario.
Click on create a webhook and call it MI_C04_U04_W. Click Save to save your webhook.
The module is waiting for a request to determine the data structure, let’s do it with Postman.
Click Copy address to clipboard to copy the webhook URL.
Go to Postman and create a new request by clicking +. You will have to create a request that sends the information about the cleaning tasks.
Select POST as the method and paste the webhook URL in the URL field.
The items to be cleaned are passed as a JSON string in the body so select Body > Raw and make sure that JSON is selected.
Copy this JSON document and paste it in the body section. It contains the same items that you will pass in the HTTP request.
Click Send to determine the data structure.
Go back to your scenario and see that the data structure has been determined. You will now be able to map the items you sent with the body in the next modules. Click OK to close the module.
Next add a Google Sheet > Add a row module.
Connect it to your Google account and under Spreadsheet ID select the MI_C04_U04 spreadsheet that you have just created. Select Sheet 1 under Sheet Name.
Time to map the items. In the ID (A) field map the id from the Custom webhook module and in column To_clean (B) map the to_clean item. Click OK to save the module.
The scenario combines an instant trigger (webhook) with an immediate scenario scheduling. This is already the default setting, so nothing to change here.
Notice that the icon on the Custom webhook module is a lightning bolt, indicating an immediate scenario execution.
Turn your scenario ON so it is ready to execute when a request is received by the webhook.
Pro tip You could have used scenario 3 containing the HTTP > Make a request module to send the request to determine the data structure.
However, the best practice is to use Postman because no operations are used in this case and because you won’t have to build the whole scenario with all the modules before being able to determine the data structure.
Test it
Time to test the scenario. Work through each stage before you continue.
Go to Postman and send the same request that you have used to determine the data structure. See that the default 200 Accepted response is sent back. Go and have a look at your spreadsheet; it contains one row with the request.
Next, go to your scenario and turn it OFF. In Postman change the to_clean item to room_2 and send the request. Go to your spreadsheet and see that no new row has been added even if you have received the 200/Accepted default response.
Your webhook is ON, so the requests can be received, but the scenario is OFF, so they cannot be processed. Where has your request gone?
If you’ve guessed that it is the webhook queue, well done! This is exactly where your request is stored since it cannot be processed by the scenario.
Access the webhook queue by right-clicking the Webhooks module and selecting Show queue. In the webhook queue you can see the request waiting to be processed.
Go back to your scenario and select Run once. A pop up will ask you if you want to process existing data, select Use existing data. The request in the queue is now processed and you can see it added to the spreadsheet.
Wrap up
There are three different scheduling configurations you can use to execute your scenario:
- Scheduled
- Immediate
- On demand
In Make there are two kind of triggers (instant and polling) that start a sequence of actions. They are combined with the scenario configurations and determine the behavior of the scenario execution. Webhooks are instant triggers.
When the default settings are selected and no webhook response is present, the requests that are not processed immediately are saved in the webhook queue and will be processed when the scenario is executed.