If you’re in SaaS, you might have heard the term webhooks. But what exactly are webhooks?
To understand webhooks and their role in SaaS integrations, it is helpful to have some background on APIs and product integrations.
SaaS companies are offering more integrations to their customers out-of-the-box. These integrations are almost always built (at least partially) with an API.
An API is the interface of an application that allows other systems to request, input, update or delete data in the application. A product integration often uses two systems’ APIs to automate sharing and updating data across the systems.
For example, a CRM and Webinar Software’s APIs might power an integration that (amongst other things) enables the Webinar Software to pull lists of contacts from the CRM and also add names and emails of people back to the CRM who attended a webinar. It might also delete contacts from the Webinar Software lists that were deleted in the CRM.
In others words, APIs enable automated communication between systems that can include requesting, pushing, updating, and deleting data in both systems.
APIs work by one system sending a request to another system’s API. So the CRM might request that the Webinar Software send any new registrants for an upcoming webinar.
This request is known as a 'poll,' ‘call’ or a ‘sync’ and it can be either scheduled to happen at certain intervals or a user or developer can send a request whenever they choose to.
Because these requests usually operate on a schedule, it can result in a lot of requests and a lot of computing power. All this activity might be for little data if not much was updated since the last request.
There will also often be a lag in the accuracy of the data in one system as most APIs have limits that preclude scheduling a call to go out every millisecond or second. If your CRM is scheduled to sync with a form on your website every 10 minutes, for example, then the list of contacts in your CRM who submitted a form might be out of date for part of that 10 minutes.
In contrast to an API integration, which regularly polls the other system, a webhook is set up once and then just sends data whenever a particular event occurs.
Our Webinar Software, for example, might have a webhook that allows other systems to get the contact information of anyone who registers for a webinar. In that case, whenever someone registers for the webinar in the Webinar Software, their info will immediately be sent to our CRM.
The advantage of a webhook is that it sends data in real time, whenever the relevant event happens. In many business use cases, having information in real time is important to the business.
Another advantage of a webhook is that it doesn’t involve communication when no relevant events have occurred. An API integration between a CRM and a Webinar Software would have the CRM regularly calling the Webinar Software for new registrants - even when there are no new registrations. This can be a lot of wasted activity and computing power.
Webhooks are relatively simple to set up from a technical perspective. They require setting up a POST request and endpoint in a system that is going to send the data, and the system receiving the data must have a URL to send the data to.
The main reason not to use a webhook is that they do not have as much functionality as an API integration. Webhooks do not enable pushing, deleting or updating data in another system. They only enable receiving data. So they can’t be solely used for more complicated integration use cases that require bi-directional communication or deleting data.
The other disadvantage is you won’t necessarily know when the other system is down or if it failed to send data. Since you only receive data when an event occurs, if the other system does not send data it could mean no events are occurring or their system is down.
In contrast, with an API integration, when you poll another system on schedule, you will get an error response. With a webhook, you have to put some other mechanism in place to know when the other system is down, if your use case requires that information.
In addition, if your system is down when the other system sends data via webhook, it will usually only re-try a certain number of times before giving up. So you have to ensure that your setup has a way to get the data you need if your system goes down for longer than those re-tries.
Most larger SaaS companies offer REST APIs and webhooks. Webhooks are most suitable for when the end user needs data to be pushed from one system to another in real time or when the use case makes webhooks much more efficient to run.
Here are some examples of use cases where a webhook would likely be suitable:
From a business perspective, whether to use webhooks mostly comes down to whether the data needs to be moved to another system right away. Usually this is because the user or system needs to be notified of something happening right away in order to best do its job.
A demo request, for example, that is responded to 10 minutes later will have fewer conversions than one that is responded to right away.
Issues around efficiency, data limits, and security will need to be worked out by developers. Developers should also ensure that when either system is down, there is a mechanism for the reconciliation of the data in both systems.
So what are some real life SaaS examples of webhooks?
Twitter has account activity webhooks where you can be notified if you receive a direct message, tweets, reply, likes, and more.
This is a good example of where the business objective is met by having real time data. A social media manager at a company will do better if she can respond immediately to someone re-tweeting, replying, or direct messaging the business account.
The receiving system might be a social media management tool, like Hootsuite or Hubspot, or, more simplistically, it might be a tool like Slack.
In contrast, Twitter’s Engagement API is not a webhook. This API allows systems to retrieve all the engagement data on their account and tweets for a certain time period. This data is important to judging and tracking marketing performance but there is less need, from a business perspective, to have it in real time.
Similarly, Twitter’s Search API allows another system to search all the tweets and return ones pertaining to the search. While this can provide illuminating data for analysis, its business use case does not usually need to be automated to real time.
Shopify has a number of webhooks available both to enhance efficiency and to accommodate the real time needs of e-commerce.
When a customer is going through the process of purchasing items, paying, disputing a transaction, canceling an order, or getting a refund, real time automated responses and follow up can enable better customer service.
Getting real time notifications around inventory, customers, and products can ensure all inventory management systems, marketing, and shop displays are up to date.
Shopify also has REST and GraphQL APIs that cover more functions, including shipping and fulfillment, reporting on business performance, storefront content, product info, and more.
Depending on your product and tech ecosystem, webhooks might add value to your tech partners and customers. If your customers need data to move from your system to another in real time to meet their business objectives, or if your customers only erratically need a particular type of data to move from your system to another system, a webhook might be the best solution.