What is a Webhook
Usually, when we want to pull some data or ask a remote service to perform something for us, we make a request to it and we wait to get back a response. When the desired action is repetitive, we just have to keep making requests in specific time intervals, something that is more commonly referred to as polling. This approach has a number of advantages and disadvantages as you can imagine. On one hand, we have total control over the requests and when the data will arrive (or when the service will execute the requested action), but on the other hand we might delay too much before we learn that something had happened and thus new data has been created, or we might put extra stress on the service making frequent requests. Webhooks are an elegant solution to the before mentioned problems and in general for situations where polling is not preferred.
A Webhook, is an HTTP callback, that we register with a service and which is triggered every time a specific event occurs. When that happens, a POST request is executed to send an event notification to a predefined URL that we have provided to that service.
What actually happens is that compared to the polling strategy where we make a request to the remote service to do something, we actually give a URL to it and ask it that whenever something new happens, send me something to it.
Webhooks & Intercom
Intercom is a popular customer engagement service. This engagement might have different forms, depending on our needs, it can be marketing, sales or customer support. Anything that we need, related to our customers that require communication, Intercom can help.
Customer engagement is a stochastic process, a customer might appear at any time and the need for communication might arise. In such an environment, Webhooks fit quite natural and can be useful for a number of different scenarios and is no surprise that Intercom offers to its users the ability to create and operate Webhooks. In this post, we’ll list the most important use cases of Webhooks on the Intercom platform.
The first use case for using Webhooks together with Intercom is for collecting customer related data that we would like to use for analytics and other reasons. By registering a Webhook for each event that Intercom supports, we will get a notification whenever something happened with all its related data. For example, when a new conversation occurs, Intercom will send the conversation part on the URL we have provided to the Webhook. This approach for data collection has the following pros & cons.
- We will get the data as soon as it is generated on the platform. So for cases where we want to acquire the data as soon as possible, a Webhook is ideal.
- Our data management system will be simpler. As we won’t have to worry about scheduling and running long lasting data pulling processes.
- We usually do not have access to all the data through Webhooks. Intercom supports some specific events that can be paired with Webhooks.
- If an event happens and the *Webhook *is triggered but our service is down for any reason, we might lose data. This of course, depends on how the *Webhooks *have been implemented by the service but it’s quite common that data can be lost.
|Sync your customer success data from Intercom to any data warehouse. Analytics-ready data with no hassle.||Integrate Now|
Real-Time Event Processing
This is the use case where Webhooks *really shine. Anything that requires event processing in real or almost real time, benefits by the existence of *Webhooks. Such an example is a notification system where notifications will be sent to our team every time specific events happen. Using a polling strategy for pulling data that will be fed to the event processing engine is not a realistic option at all as real-time or almost real time semantics are really difficult to be achieved in this way. The pros and cons of *Webhooks *for event processing.
- Data will be pushed to the system as soon as possible and thus using Webhooks becomes more or less a necessity for such a system.
- Fewer data processing will be required, mainly because Webhooks are directly related to events and thus the data is better structured for this kind of systems.
None. Really, for such systems, callbacks and in general push instead of pull like mechanisms are more or less a prerequisite. The only issue might be again the possibility of data loss, but event processing systems should be tolerant to that.
Another common use case for Intercom Webhooks. For example, consider the case where you would like to notify your team on Slack when a new customer sign-ups, or even do more complicated integrations using services like Zapier and IFTTT. To do that, an event on one service is usually associated with the triggering of a specific action to the other one and of course, the communication happens in most cases using Webhooks. We can’t really mention any pros and cons here or any alternatives, especially when the integration is between services from different vendors over the Internet.
Webhooks extend the core functionality of the Intercom platform in different important ways.
- By having them we can integrate Intercom with other services that we use and greatly enhance our productivity.
- We can also use Webhooks to feed notification and real-time event processing systems.
- Finally, we can use Webhooks to pull data out of Intercom and do analytics.
Especially for (3) a good strategy is to combine both Webhooks and a polling mechanism communicating with the Intercom API to have an as complete as possible view of all your customer data. If this is what you are looking for, you should check Blendo which allows you to easily utilize both methods to consistently pull your data from Intercom and push it to your database or data warehouse solution of choice.