19 Jul 17, 2018 — https://sf.gl/1583

What is a Webhook?

The Webhook is the Web's way to integrate completely different systems in semi-real time.

As time has passed, the Web (or more precisely, HTTP, the protocol used for requesting and fetching the Web site you're currently reading) has become the default delivery mechanism for almost anything that's transferred over the Internet.

Webhooks are used everywhere

Webhooks are used in lots of places. Here's some examples of where Webhooks can deliver value:

  • Notifying an ordering system that a payment has been completed, so the order can be shipped
  • Adding a customer to a Relations Management system after they sign up on a Web site
  • Transmitting events from e.g. a newsletter campaign and deliver it to an analytics platform

If it's on a network, it can send Webhooks

Refrigerators, industrial control systems, lightbulbs, speakers, routers, anti-virus programs – everything is controlled via the Web these days. It's not because HTTP is perfect, fast, or fault tolerant, rather, it's because everybody speaks it. It's very easy to send and receive a HTTP call. In fact, many programming languages can do it in a single line of code.

The Web page you're viewing right now – its URL being https://simonfredsted.com/1583 – might as well have been a Webhook. When your browser sends a request to it, my Web server sends a response back containing text, images and layout information.

The only difference between this Web site and an actual Webhook is that the sender is not a browser, but some sort of automated system, and probably contains some additional data rather than just which blog post you want to see. And in response, the system would have received a bunch of raw data rather than a formatted Web document.

With a URL, you can therefore send and receive information to and from any other system, often in the form of an API, a defined set of functions (where each is a specific URL) that can act on a system.

But what if a regular API, where I contact it myself and receive the data at my leisure, isn't enough? What if I don't want to constantly ping the API for data – what if it could just let me know when something changes? As that became a growing need, the word for applications exchanging information automatically like this came to be known as a Webhook. Something happened? Ping my Webhook and I'll know!

A general method of setting them up also started taking form: subscriptions. On most systems, this involves setting these subscriptions up by – you guessed it – a personal fax to the system operator, who can then program it into the mainframe!

Sorry, just kidding. Webhooks are of course also set up via the Web, and many sites offer either a user interface for setting them up, or even an API: that way, other applications can subscribe and unsubscribe to your application as they please.

Implementation is up to the developer

Webhooks aren't a standard, but most developers implement them in the same way: When an event happens in your program that another program is subscribed to, go though each subscription and check whether it has access to view that object, and if so, send a HTTP request to the subscriber's URL.

The content of the request can then be either the actual content (mostly in JSON or XML format), or a reference to the content that can be fetched later: something happened, but call this other URL to see exactly what happened. Doing it like that can save on bandwidth if you batch requests later, for example.

Obviously, and the whole reason we're doing this: it is then up to the subscriber to carry out an action on the Webhook if it is needed.

A diagram depicting a common way to handle webhook subscriptions in a scalable, event-based manner

A diagram depicting a common way to handle webhook subscriptions in a scalable, event-based manner

Did my toaster send a Webhook about my toast finishing? Better send a text via Trello to remind me there's breakfast! (Maybe I have a bad short term memory. What's it to you?)

But what happens if problems occur along the way?

Error handling is important for a robust system

If you don't take certain precautions, Webhooks are very prone to failure and lost data.

If I'm suddenly unable to send webhooks to my subscriber, it might be a good idea to re-send it later at some point. But how long should I wait? If I send it 1 second after, the subscriber is probably still down. Maybe 10 seconds or 10 minutes is better for a specific use case. Maybe they'll be completely bombarded by my retries and they'll be worse off. Maybe random retry times, or constantly increasing (e.g. exponential backoff) ones would solve the problem.

You might also not want to keep sending a Webhook an infinite amount of times. That is a long time, after all.

Speaking of time: it might be worth it to consider timeouts for your use-case. Even though you're great at implementing fast software, maybe your customers aren't, so set a timeout that's reasonable for all parties, or you'll risk delivering duplicate Webhooks to your customers when retrying (due to said timeouts), or maybe they'll never get their data.

Maybe you want to give control to your subscribers: let them view a log of the failed requests, and let them re-send specific requests at their leisure.

Webhooks should always be queued

All of these ways of increasing robustness rely on a way to queue your calls or process them asynchronously: don't send them while delivering the request that triggers it, for example. Otherwise the user would be waiting on both the system doing its thing – and the Webhook subscriber(s) responding! Again: you can't control how long the recipient takes to answer.

Queuing is also a good idea on the subscriber side. You can't be sure that those you're subscribing to will wait forever to hand over the requests; you need to answer webhooks quickly, a couple seconds should be more than plenty to queue your action and return a response. So queue your actions, too!

As they say: your webhook should do almost nothing.

How to test Webhooks

What if you want to get to started with Webhooks, but don't have a server (that's open to the Internet) set up to receive them? What if you're developing a Webhook-based system, and you just want to see whether it successfully sends out Webhook requests?

For that use case, I created Webhook.site back in March 2016 – I often needed to test webhooks, so I decided to build my own site that worked like I wanted

Later, more features have been added to Webhook.site, like transformation and redirecting, sending emails, custom workflows, and even scripting. That way, you don't have to worry about managing servers and uptime just to, say, convert a Webhook to an email (or vice versa.), send a push notification or running a SSH command on a system. You simply use Webhook.site to automate any given Webhook.

What can I use Webhooks for?

Almost every cloud service has some sort of Webhook functionality, but if you're not a developer, they're hard to use. For that, check out Webhook.site mentioned in the previous paragraph. There's also IFTTT (if this, then that) or Zapier – under the hood, they use Webhooks.

What do you use Webhooks for? Let me know in the comments!

19 Responses to “What is a Webhook?”

  1. Vignesh

    Useful. thanks

  2. TL

    Thank you for this article. Also, I’m a fan of your webhook tester.

  3. David Multer

    All kinds of developer integrations like Stripe, Drip, GitHub, etc. Also looking for ways to help other developers do a great job integrating webhooks.

  4. Edward Yang

    Thank you for sharing, I’m very interested in Jira webhook test with your tool.

  5. Eric

    I understand that webhooks are very useful when included in a webapp.
    If we want to receive data from a remote site to record in our DB, do you think is it the best way to receive the data ?

  6. Simon Fredsted

    Hi Eric, depending on your requirements regarding latency, performance, etc., webhooks might be able to solve your issue. You could also look into DB replication across WAN.

  7. Gerard ONeill

    I was trying to implement a webhook for Hubspot, and I thought to contact another site (our own), I’d have to implement CORS. So I hooked up your URL (Awesome) as the target.. and found that the “simple” CORS call included all of the data.. Since I didn’t need a response, I don’t have to change anything! I love those AHA moments.

  8. Introduction – MageHook

    […] What is a webhook? […]

  9. Six Key Components of an Analytics Data Pipeline - Reflective Data

    […] in data pipelines are usually invoked by webhooks that put all events into the processing queue where they are validated, enriched and […]

  10. Nick

    So its a ‘hook’ because its not a simple response to a call,, the ‘response or reply’ is hung up (like a jacket/raincoat) on the ‘hook’ until its needed to be used? – out of bread, lets go to the market, oh, its raining outside, I better take a coat!?

    Im just helping my tiny brain understand sorry.. lol

  11. Simon Fredsted

    In programming, the word “hook” comes from the phrase “hooking into” something, so a Webhook is hooking into an event, or making the application call it whenever the event happens. The application has a list of hooks that must be notified whenever a given action occurs, but since Webhooks are usually asynchronous, the application doesn’t wait for a response.

    In your example, let’s say there’s an app that has created a Webhook for when you’re picking up your keys from the table (before going outside) — the event. When called, it can then check the weather and send you an alert on your phone saying that it’s raining.

  12. Ulrike

    Thank you for the nice summary. I appreciate how you deliberately try to explain this in easy to understand terms and examples. There is no value in making simple things sound complicated.

  13. Fast webhook testing | CloudMonitor

    […] From the author’s blog, he has posted an article about what webhooks are: What is a webhook? […]

  14. Marcio Nogueira

    API is to passive, as Webhook is to active.
    When you need to query data from a system, you use an API.
    When you need to send data to a system, you use a Webhook.

  15. webhook.site – blog.donazzon.com

    […] Webhook.site lets you easily inspect, test and automate (with the visual Custom Actions builder, or WebhookScript) any incoming HTTP request or e-mail. What’s a webhook? […]

  16. KK

    How is webhook conceptually different from a callback ? Callback or pub-sub models existed even prior to the web in desktop UI world , is it that we are bringing the same concept to HTTP world now?

  17. How to download leads from Google Ads - Privyr Blog

    […] Webhook is a tool that allows communication and data sharing between two applications. With a Webhook […]

  18. Chris

    Great information. I want to connect a ESP8266 module to IFTTT. I find many articles that send data/webhook TO IFTTT or somewhere else. But not the other direction to a specific pin on a piece of hardware.
    I want to have an event fire IFTTT then send a webhook to an ESP8266 module on wifi. If I must, I could also use an intermediary, like Blynk, to process the webhook and then fire the ESP8266.
    Would like to find a project or article where this can be accomplished. And I can find or derive the specifics for the URLs that I need to accomplish this.

  19. How to Download Leads from Google Ads 2024 - baraac.shop

    […] A Webhook is a tool that allows communication and data sharing between two applications. With a Webhook integration, you can automatically send information from one app to another using a unique URL. This means you can also use Webhooks to automatically send leads from Google lead forms to another system (such as your spreadsheets or CRM) as soon as someone submits interest. […]

Leave a Comment

Note: Your comment will be shown after it has been approved.