What are webhooks and how to get started?

Let’s start off by getting straight to the point: Webhooks are a way for one system to send updates to one or many other systems.

That’s it! That’s all they are.

Have you ever made an API call? Webhooks are very similar, but instead of making a call to an API endpoint, a webhook calls one of you’re endpoints.

How about a real-world situation: You’re using a payment provider, let’s say, Stripe, to manage your subscriptions in a SaaS platform. The recurring monthly charges happen behind the scenes, but you need to record the data about each subscription in your CRM.

To achieve this you can create a webhook in Stripe that will fire every time a subscription is paid. This webhook calls an API endpoint in your system — from there you can add the data to your database!

Webhooks vs APIs

“What’s the difference between a webhook and an API?”, you might ask.

This comes down to who is “calling” who. When you make an API call, you are calling a system and asking for data. However, a webhook calls you and throws the data at you.

I use the term “throw” because webhooks don’t want to wait until your code is done processing before they are given a successful or failed return status.

Using the above example with Stripe subscriptions, to get data each time a subscription is paid you have to create a webhook in Stripe and an endpoint in your system.

To get the same data with an API call you’d have to write code to constantly poll Stripe. Since you are constantly polling you’ll have to manage the polling code as well as the other functional code.

At the end of the day, both solutions work! But the event-driven nature of webhooks makes receiving and working with data much easier.

The right and wrong time to use webhooks

No matter how great a tool is, it might not be the right choice for every situation. Webhooks are no exception - they can be a helpful tool, but if used in the wrong situation, they can become a hindrance.

When to use webhooks

My personal opinion: if you can use webhooks, do it! Not all systems can send or receive webhooks, though.

Webhooks are great for working with time dependent data or apps where you’d have to constantly poll to get data.

Webhooks have lots of indirect positive implications as well. For example — the less code a developer has to write, test, and maintain, the faster they can ship features. Webhooks can help you remove boilerplate code, cron jobs, and some duplication-checking, allowing you to complete features faster.

When to not use webhook

On occasion, processing data can take a long time. If that’s the case, a webhook may not be the answer. Webhooks generally need a quick response based on if the data was received or not. Long-running processes can cause webhooks to time out if they wait too long. The sending platform should have guidelines on what is “too long” for a webhook to wait.

Webhooks may also not be the answer if the system you are sending data to has strict API limits. As an example, Salesforce has strict limits on calling its API. Using webhooks that push data into Salesforce could cause you to unknowingly break these limits and have to wait until they reset.

If you are trying to integrate a webhook with Salesforce, using a tool like Quick Freeze will be a good call. It’ll allow you to batch the webhooks and use a single API call from within Salesforce to get the data so you stay well within your org’s API limits.

Get started with webhooks

To get started with a webhook you’ll need two things.

1. A system that has the ability to send webhooks
2. An API endpoint in a system you control

Once you’ve got the sending system setup to send the data to your endpoint, you’re good to go! No cron jobs, polling functions, or deduplication checks.

Local development with webhooks

One of the challenges with webhooks is being able to use them while developing locally. Most platforms won’t allow you to send webhooks to non-secure URLs or localhost. Luckily there are quite a few tools out there to help with this.

Three of the best webhook tools:

1. Ngrok — ngrok creates a public URL that forwards traffic to your localhost. This is a great option to use when developing locally because it allows you to test your webhook endpoints like they’ll be used in production
2. Quick Freeze — Quick Freeze can act as a bridge between the sending system and the receiving system. If the receiving system has API limits, doesn’t have an inbound API, or can’t be accessed by external systems, Quick Feeze can catch and hold data until it’s ready to be moved out.
3. RequestBin — Request bin allows you to receive API calls and webhooks events from a generated URL, similar to ngrok. You can also view the data, integrate with other apps/platforms, and execute steps on the data.