Unit introduction
Welcome to the first unit of the “Webhooks” course.
You might remember that in the last course we briefly touched on webhooks.
In this unit you will go deeper into the world of webhooks, explore what they are, how they work behind the scenes and how they relate to API and HTTP calls.
By the end of this unit you will understand:
- what webhooks are
- when to use webhooks
- how you can add webhooks to your scenarios
Let’s get started!
Webhooks recap
We’ve mentioned webhooks briefly back in the unit “HTTP to webhook” in the Introduction to HTTP course, as well as in Make Basics.
But it’s been a while, so a quick refresher would be helpful!
Which of the following statements are true about webhooks?
- Webhooks are a method of receiving notifications about an event as soon as it occurs.
- Webhooks can be used to trigger different scenarios in Make.
- Webhooks can be called using the HTTP protocol.
Webhooks overview
You might recall from the previous course Introduction to HTTP, that webhooks are tools used by Make to automatically receive updates or notifications when an event occurs in another application or scenario. The information shared in the notification/request is used to trigger the scenario associated to the webhook.
Olivia runs an online shop called You Can Dress Your Own Way. Every time a customer places an order, she instantly receives a text message with the items requested. She can choose to process the order straight away or handle all orders at a scheduled time later in the day.
Same with webhooks, when they are active, they are ready to receive any requests that are made to them.
When a request is received, the scenario is started immediately, on a specific schedule or on demand, according to the scenario settings. You will learn more about this later in this course.
How do webhooks work?
You have seen that webhooks enable applications to send notifications automatically when certain events occur in other systems.
But how do they actually function? What happens behind the scenes to ensure that these notifications reach the right place at the right time?
Let’s take a closer look at how webhooks work.
How do webhooks receive requests?
Webhooks provide a unique URL that you can call to make your request.
Imagine that your favorite restaurant MakeDonald’s has a phone number you can call and request exactly the food you want. You want to use it to request that cheeseburger you’re craving, right? Just make a quick call and send your request!
If the requests are not processed right away or need to be reprocessed due to an error, they are stored in the webhook queue. You will learn more about this later in this course.
How do you make a call to the URL?
You use HTTP to make the call and share your request with the webhook and you will learn how to do it in the next units.
It is like the phone call you’re making to order that juicy cheeseburger, you need to use a specific language and structure to make sure your request is clear.
Isn’t this similar to APIs?
Exactly!
As you’ve seen in the HTTP course, APIs are used to communicate between different applications and they have endpoint URLs that are used to provide a service.
A webhook can be seen like a single API endpoint. It provides a service, and you use a HTTP call to make a request to it.
Note: When you provide a webhook by exposing its URL and wait for others to send requests to it, you are the provider. Vice versa, when you make an HTTP request to a webhook URL, you are the consumer. With Make you can create scenarios to be either the consumer or the provider.
Why do you need webhooks if you have APIs?
APIs:
- Official documented services from the vendor
- Does not change often
Webhooks:
- Custom services created by the customer for their project
- Flexible but not officially documented by the vendor
Webhooks make it easier and more flexible to share new services.
While software vendors provide official APIs with set features and documentation, these APIs are fixed and not easily changed.
If a customer needs to offer a service from their own project, they can’t always ask the vendor to add a new API endpoint. Instead, they use webhooks customized for their specific needs.
Why are webhooks useful?
Webhooks are useful for several reasons.
Connect Different Apps
Webhooks are a great way to connect different applications to Make, or to connect different scenarios in Make. That way you get data when something happens on the other platform/in another scenario.
Webhooks are already present in some Make modules and even if an app is not available in Make, you can use the Custom webhook module if the app that you’re using supports webhooks.
Get Immediate Notifications
Webhooks enable real-time communication between systems, and allow you to get data instantly when something happens.
As soon as an event happens the app makes an HTTP call to the webhook that is notified about the event. The request is registered and the information is used to trigger the scenario.
Save Credits
You can also save credits with webhooks, as they use credits only when there is an actual event/change.
If you schedule your scenario, for example every 15 minutes, then you would use credits every 15 minutes, even if there is no new data.
If you use webhooks, the request is immediately received by the webhook. If the scenario is active, it gets executed when the request is received.
Note: Whenever a webhook scenario is triggered, the custom webhook module consumes one credit.
Webhooks in Make
Let’s delve deeper into the webhooks in Make.
Custom Webhooks
In Make, you can add webhooks in your scenario using the Custom webhook module from the Webhooks app. This is a generic app in Make that you can use to integrate with services that don’t have dedicated modules yet, or to create your own advanced integrations. The Custom webhook module allows you to create a URL to which you can send any data.
Webhook Response
The Webhook response defines how the webhook answers. This is what the consumer receives when they call the webhook. When a request is sent to the webhook, the default response by Make is status 200/Accepted.
If you want a specific response, you can use the Webhook response module to customize it. You can also use a router to create different paths according to different request parameters or different behaviors in the scenario.
For example, if everything went as expected, you could send a response “Great success!”, but if something went wrong you could send an “Ooops fail” response, or whatever you choose.
Custom Mailhooks
The Custom mailhook module is specific to email servers, and it is used to get notified when a new email is received, for example Gmail → Watch email.
It’s good to know this module exists, but we will not focus on it for now. Just remember to be careful NOT to select the Custom mailhook module when you actually want to select other Webhooks modules.
App-specific Webhooks
Some modules in Make have webhooks already implemented in them to listen for data coming from a specific app. As they are webhooks, they can receive requests, have a queue, etc. The only difference from Custom Webhooks is that they have already been set up for you.
In Make, some apps provide different webhooks for different types of events (for example Contact Created, Task modified, etc.), and some other apps provide one single webhook where you can choose the event that will call it.
For example, in WooCommerce you can use the New Event module to subscribe to notifications for orders, customers, products or coupons. In this specific case, you select the specific type of event you want to watch when creating the webhook by selecting it from a dropdown.
How to Recognize Them
As you’ve learned, webhooks have already been implemented in some Make modules. Let’s see how to distinguish them.
Did you notice that some modules have an INSTANT tag? This means that this module contains a webhook!
Here you can see an example of a Tally → Watch new responses module, which is an app-specific webhook.
When you have filled a form, you can ask Tally to call a Make scenario via a webhook.
In this case, Tally is the consumer of the webhook, and Make is the provider.
Webhook use cases
Let’s have a look at some examples of where you can use webhooks.
Syncing data
With webhooks you can sync your data faster across different platforms because you are immediately notified when an event happens, you don’t need to poll information on a schedule.
For example, let’s imagine you want all your contacts to be synced between HubSpot and Salesforce. You can have HubSpot call a webhook scenario every time a contact is created or modified. This scenario would then immediately connect to Salesforce and create or modify the contact.
Instant notifications
With the help of webhooks, you can get instant notifications on your phone.
For example, you can configure a webhook scenario to be triggered every time there is a new order in Shopify. Then, with the help of the scenario, you can send a Slack/WhatsApp/Mobile App/SMS message to notify anyone you want about it.
Creating a chatbot
When creating a chatbot, you need webhooks to receive messages from chat apps like WhatsApp, Discord and Telegram.
For example, you can configure Slack to call your webhook scenario every time a user types a specific command, and you can have the scenario reply to the user instantly.
Reacting to users’ submissions
You can use a webhook to receive an instant notification when a user fills a form in your favorite social media.
Your marketing team may want to be instantly notified when a user submits a form to show interest in a product your company sells.
You can build a webhook scenario that gets immediately notified when a user has filled a form, and then passes the information to the relevant sales team.
Create a webhook
Now that you know a bit of webhook theory, let’s create a webhook together. Work through each stage before you continue.
In this exercise, you’ll create a new webhook for training purposes. You’ll see how to create a webhook from a scenario and using the Custom webhook module in Make. Let’s get to it!
On the Make dashboard, click the Create a new scenario button. You will be taken to the scenario editor.
Name your scenario Make Intermediate Test Webhook.
In the scenario editor, click the ”+” button to create a webhook.
In the search bar, type “webhook” and select the Custom Webhook module.
Then click the Add or Create button.
Enter a name for your webhook (e.g., My Make Intermediate Test Webhook).
Click Save.
Did you notice that we clicked Add webhook? It’s because a webhook is a different object from a webhook scenario.
- The webhook scenario is the scenario that will process the data received by the webhook.
- The webhook is an object that is created externally to your scenario, but linked to it. It contains a URL that listens to requests, a queue to store the data sent if needed, and it can be active or inactive independently to your scenario.
Make will generate a unique webhook URL for you. After clicking Save, you will see the webhook URL. Copy this URL: it’s your new webhook URL. Click OK and save your scenario. Make is now listening for the data sent to this URL. This URL will be used by the external service to send data to Make. Even if the scenario is inactive (OFF), the webhook is active (ON) by default, ready to receive requests.
Note: The webhook URL starts with HTTPS. This protocol is used instead of HTTP to enhance security by encrypting the data transmitted between the client and server.
IMPORTANT! Keep your webhook URL secret and share it only with trusted partners and services that need to send data to your application. This is crucial for maintaining the security and reliability of your system, minimizing the risks associated with unauthorized access and ensuring that your webhook integrations remain secure and effective.
Access your webhooks
In Make you can access all of your webhooks from the Webhooks menu.
Navigate to the left menu and select the Webhooks tab. Clicking it will open a list of your webhooks.
Webhook list
In the Webhooks menu, you can find a list of all the webhooks you have created with their associated information.
You can click on the webhook to see its details.
You can use the search bar to look for a specific webhook. Type “My Make Intermediate Test Webhook” to find the one you’ve previously created.
When data arrives to a webhook and the call is not processed instantly, Make stores it in the webhook queue. The limit for the number of webhook queue items depends on your usage allowance, which is a part of your subscription.
Webhook detail
If you select one webhook you can find more details associated with it.
General information
The General information section provides details about the webhook itself:
- Webhook status: Active
When you create a webhook, it is automatically active (ON) by default. This means that the webhook is ready to receive and register any request that is sent to its URL.
If the scenario is ready to be immediately executed as soon as the data arrives, the request is immediately processed. Otherwise, the request and the data are saved in the webhook queue.
You’ll learn about the webhook queue in more details in Unit 4.
- Service: gateway-webhook
- Webhook URL:
https://hook.eu1.make.com/...This is your webhook URL; you can send requests to this URL.
- Webhook UDID:
...
Webhook’s scenario
The Webhook’s scenario section provides details about the scenario connected to this webhook:
- Scenario status: Inactive
Here you can see the details of the scenario connected to this webhook (scenario status, scenario ID, and scenario URL).
Notice that this scenario is inactive. This means that it is not ready to be executed when a request is made to the webhook URL.
In this case, if there is data sent to this specific webhook, because the scenario is inactive, it will go to the webhook queue to be processed later. You’ll learn more about this in the next units of this course.
- Scenario ID:
259472 - Scenario URL: Make Intermediate Test Webhook
This is the URL of your scenario. Clicking the scenario URL will take you straight to the scenario associated with this webhook.
Webhook logs
Finally, let’s look at webhook logs.
If you select any of your webhooks from the Webhooks list, this will load a summary of the webhook, with 3 tabs that state Detail, Logs, and Queue. Click the Logs tab to load the details of each instance of this webhook. This will display the status of the webhook (success/warning/error), the date created, and the size.
Note: Logs are automatically removed after 3 days. If you are on an enterprise plan, the webhook logs are removed after 30 days.
You can filter by the webhook status or when the webhook was created by clicking the filter icon next to the STATUS or CREATED columns.
Clicking the Detail button for any log entry will load a summary of the webhook execution. This summary includes:
- Request: The time, the method (e.g., GET), the URL query, etc.
- Response: The HTTP status code (e.g., 200 if successful).
- Parsed items: The data extracted from the webhook payload.
Have a look at your webhook details to see which information you can find there.
Webhook vs webhook scenario
As you’ve seen, a webhook is created within a scenario, but the webhook itself is a separate object:
- Webhook scenario: the scenario containing the Custom webhook module that will process the data received by the webhook.
- Webhook: an object that is created externally to your scenario, but linked to it. It contains a URL that listens to requests, a queue to store the data sent if needed and it can be active or inactive independently to your scenario. Remember that if the webhook is active, no matter which status the scenario has, the webhook can receive requests that are made to its URL.
This is similar to the concept of connections in Make. You create a connection to a specific app inside the scenario editor, but the connection itself is separate from the scenario.
Let’s take your Google connection as an example. You set up your Google connection when you configure the Google Sheets or another Google app. That Google connection is separated from that specific scenario, and you will find it in the list of connections.
Note: In Make a webhook can be associated to only one scenario. It is not possible to use one webhook in multiple scenarios.
Summary
Let’s revise what you have learned in this unit:
- Webhooks are used to provide a service.
- Webhooks are a method of receiving notifications from another application or scenario, that an event has happened, as soon as it happens.
- When you create a webhook, it is automatically associated with the specific scenario, but it is a separate object.
- In Make one webhook can be associated only to one scenario.
- When a webhook scenario is triggered, the custom webhook module will consume one credit.