API vs. Webhook: What’s The Difference?

As the internet and mobile technology become more complex, websites and software are being asked to do more autonomously, and to do more in communication amongst themselves, between software and software, website and website, mobile app and mobile app -- without human interface directly managing each interaction. It’s in this area of technological development that APIs and Webhooks come into play. They are two ways in which the internet, as it were, talks to itself.

But while both Webhooks and API are part of the coding infrastructure which tackles this unique internet issue, they are not interchangeable, and they aren’t the same thing. But what are the differences between API and Webhooks?

In short, they provide two different approaches to a range of similar challenges, and each offers its own range of uses. By reading this article, we hope to give you a general sense of what these are, so you can make an educated choice around whether you need one or the other, and which one will help you do the job you need done best.

What Is an API? And What Are WebHooks?

So what are APIs? And what are the uses of APIs?

In short, an API, or Application Programming Interface, is a go-between that helps the user who has accessed a website speak to the source of information the website is displaying.

In other words: the API is the waiter who takes the user’s order and carries it to the kitchen (the system or server in this instance). In the case of APIs, the waiter might also carry your order to another restaurant in order to bring you back the meal you want. (This changes the metaphor, but you’ll see what I mean below!)

Some concrete examples of APIs include:

• The Google Weather Widget:

This is the weather information that Google displays in the top bar when you search for a town or city. Because the Google interface is not creating the weather data via their own coding or a Google app (for now…), but rather seeks this information from an external source -- in this case, Weather.com -- they use an API to request data from that external system, and collect the weather details, which Google then reformats for display on their search engine webpage.

• “Pay with PayPal” e-commerce Button

Have you ever been about to pay for something on a third-party website (a new mouse, a necklace, a specialty coffee bean) when it gives you the options to pay with your credit card, or pay directly with PayPal?

This option uses API integrations to ensure you can pay with PayPal, and no one but PayPal knows or sees your private banking information. In this way the API is the waiter: it carries the amount you’re spending to PayPal, and then the API/waiter carries back authentication and purchase confirmation data to the e-commerce site.

• Travel Booking:

When you search Kayak or CheapFlights for the latest deal to get you from point A to point B, those sites don’t have databases full of up-to-date information on every airline flying to every city in the world. Nor are they calling Karen at the Delta Ticket Sales desk to check on the dates you’ve searched.

Rather, they use a type of API (a third party web API) to send data requests to external applications in order to collect flight and travel information from exterior travel companies or airlines.

Kayak, for instance, uses an API to send your time and place requests to, say, Delta, and then they use another API to send an update on Delta’s availability, and possibly even another to process your booking. That way, you get up-to-date info and can make a real time booking, without having to ask Karen at the Delta Ticket Sales desk to call you back with updates.

A Webhook serves a similar purpose, but does so differently, as webhooks have different uses. Unlike the API, which shows up when you call it (“Excuse me, waiter?), a Webhook is an automated message that one web or mobile app sends to another web service or mobile app when it’s triggered by a specific user action. It’s called a “web” hook, because this information is sent through HTTP (i.e. the web) and is hooked (i.e. triggered by) certain actions.

So to tweak our restaurant metaphor: it’s the computerized message that appears in the kitchen (“Customer 7 has ordered a Big Mac, a Diet Coke, and a Large Fries”) after you (or the waiter) type your order into McDonald’s standalone cashier window. There’s no go-between; it’s automatic.

Some helpful examples of Webhooks include:

• Mailchimp sign-ups

When a new user offers their email to the sign-up box, or decides to unsubscribe by pressing that button at the bottom of your email, Mailchimp uses a Webhook to trigger this action. The user doesn’t have to do anything other than offer their email, and the specific event is when the webhook itself adds them to your newsletter email list and primes them to receive your next missive.

• Shopify updates

Shopify uses webhooks to integrate and update you on the inner-workings of their fulfillment systems. When an order ships, when your accounting software receives an update, or when an event occurs like a payment is made, this triggers a Webhook which sends you information -- without any intermediary or request action.

• Twitter Updates on Slack

A third example of Webhooks in action is when you set up Slack to alert you when someone Tweets a certain hashtag or about a discussion you’re following. Rather than have Slack constantly checking Twitter for relevant messages, it makes more sense for a Twitter integration to automatically send Slack information whenever a new, relevant, message has been posted, and then Slack can send this notification your way, so you’re never, ever, out of the loop.

So... Are Webhooks A Kind of API? Or Are APIs a Kind of WebHook?

Short answer: no. Long answer: not exactly.

Let me explain.

While Webhooks and API both serve the same essential purpose -- carrying information from place A to place B -- they do so with a different imperative and in order to fulfill a different purpose.

An API is a full language embedded in an app that serves as a megaphone asking for information, editing and changing data, and bringing that data to integrate it into another site.

If you build a website or application which uses an API, you’ll probably need to work with API designers, as you’ll have to build a way for this API to ask another site for information, and you will need to create a function -- user-generated or not -- which always asks for this information.

In other words, whether your restaurant is dine-in or takeout, you will always need a waiter -- or at least someone standing at the window and saying “Would you like to supersize?”

Webhooks, while similar, are simpler.

As we’ve said, they are automated, and they only function in one part of your application. If you have a Webhook that updates you when a user has signed in to your site, then that Webhook will do only that; it’ll send that information to you via the Webhooks URL without any other interaction needed -- and that is all.

Simple. Automated. One-to-one.

Or to return to the restaurant metaphor again: Webhooks might tell the kitchen what you want, so they begin to cook, but they’ll never bring the food, once finished, to your table. APIs, however, are more complex, but they also do more; they will call your order to the kitchen, and when your food is ready, they’ll carry it out to you, wherever you are sitting.

Just don’t forget to tip your API, er, waiter.

--

If you want to stay up to date with all the new content we publish on our blog, share your email and hit the subscribe button.

Also, feel free to browse through the other sections of the blog where you can find many other amazing articles on: Programming, IT, Outsourcing, and even Management.