What are APIs and Webhooks?

APIs and webhooks are both ways of transferring, and synchronising data, between two otherwise separate and distinct systems.

Within a modern techstack, containing a large number of applications and platforms, APIs and webhooks are an essential means of ensuring that component systems can speak to each other as necessary.

(Don’t worry if you’re already a little lost, this will all make more sense.)

For mid-level and enterprise brands, customer data (be it transactional, biographical or behavioural) is now being collected across multiple properties (websites, mobile apps) and leveraged through an increasing array of channels (email, push notifications, social media messengers, WhatsApp and so on).

This creates a chain of potential silos, with each solution blind to events and customer activity happening elsewhere in your tech ecosystem.

So APIs and webhooks allow you to integrate all of these solutions, centralising and disseminating data between them.

What’s the difference between an API and Webhook?

There are certainly similarities between the two, but APIs (which stands for application programming interface, by the way, but don’t worry about that) and webhooks have some key differences.

To explain the primary difference, let’s think of data more generally as information. It can be any piece of information, in any number of contexts.

Now imagine your tech stack is a large, modern shared workspace building, with a number of companies (i.e. point solutions) spread across floors in various cubicles and offices. 

Each company specialises in collecting and/or sending certain types of information. But throughout the day, one of the solutions will need information from another to do its job better, and at some point they all need to send the most important information they have to a single place (“the warehouse”).

This is where APIs and webhooks come into play; they’re like the go-between, relaying information. However, the rules and structure around how they do this are very different.

An API is a request; one solution shouts across the room to another “Have you got that information I need yet”? If the answer is yes, and the other solution is willing to share, they accept the request and the transfer happens. Job done.

However, if the information isn’t ready yet then the request is denied. And later on, the request will need to be made again. And on it goes until the transfer eventually happens.

But webhooks are more like a long-standing arrangement between two solutions. It says, “Whenever you have the information we need just send it straight over”. So repetitive, daily requests aren’t necessary, the transfer just happens.

Or to simplify even further*, think of it like a knock on the door; an API means you must wait for permission to enter, a webhook lets you come straight in!

*Yes, I enjoy a good analogy.

What can APIs do?

To get more technical (just for a moment), APIs are programmatic requests usually written in JSON or XML format. And not only can they request data, they can also be used to alter and delete data within a third party system.

Here are some examples of what an API can do:

It can tell a third party solution to update a customer’s email address with a new one that’s just been collected from them.

It can update a CRM tool with subscription status gathered from marketing platforms for an entire audience

It can extract response data from disparate platforms and insert it into a BI tool. 

What can a webhook do?

Webhooks can do anything an API can, just without asking for permission every time! Occasionally, you see webhooks referred to as reverse-APIs. But this isn’t strictly accurate, and all it really means is that the programmer doesn’t initiate the request, it happens automatically.

An example of a webhook in retail banking would be an automated transaction alert. As soon a customer’s account is credited or debited, a push notification lets them know in real-time.

A webhook could also synchronize individual client data between systems, for example when a client updates personal information.

When to use an API or a webhook?

Deciding between an API or webhook is really a case of horses for courses; you choose whichever one is suited to the task you have.

When to use an API?

APIs are best saved for instances or use cases where the data is changing regularly, and when several values are going to be altered when the request is accepted. It’s more resource efficient to ask for this information at specific times when you know that is always going to be something to report.

Ultimately, APIs give the programmer much more freedom over how and when the transfer happens. It’s also worth mentioning that it’s possible to impose a limit on the number of requests (or “calls”) the API can make within a given timeframe. So only ask three times a day, or once every few hours, for example.

You will also see APIs used as a way of determining if the other system is operational. Because it can only accept or deny the request if it’s up and running correctly. If it’s not functioning then there’d be radio silence.

When to use a webhook?

Webhooks are typically used when the data doesn’t change regularly, or when the amount of data being transferred is quite small (a single value or event)

Webhooks are also typically better suited for real-time data transfer, although APIs can be configured for this too.

Some finer details worth noting:

• Webhooks are not universally supported by every application and system, so API may be a necessary, if not perfect, alternative in some cases.
• A webhook typically contains a small amount of data, so for larger payload an API is required.