Explain webhooks to me like I'm five

#explainlikeimfive #webhook #discuss

Top comments (4)

Frederik 👨‍💻➡️🌐 Creemers • Oct 7 '17 • Edited

When your dad's car breaks down for whatever reason, he takes it to the repair shop. It'll take a while before the people there can start on your dad's car, because they're working on other cars as well, and the repair itself will take a while. Your father is a busy man, so he won't wait at the shop until his car is done.

He could go home, and call the repair shop every hour to see whether he can come pick up his car, but that's annoying, both for your dad and for the repair shop. So rather than doing that, your dad leaves his phone number at the repair shop, and they call him when the car is done.

Translating this for grownup web developers, you have a web application where something might happen that you're interested in. This could be a post/tweet/video being published, or a previously started transaction being completed, or something completely different. This site could expose an API endpoint that you could use to check for this, but you'd have to call the API endpoint periodically (referred to as polling), in order to get the data. This has some issues:

You need to keep a process running to call the API endpoint periodically, which costs CPU and bandwidth, when most of the requests will not give you anything useful.
They get a large amount of requests to their servers, again, wasting CPU and bandwidth resources.

So rather than constantly checking whether the event you're waiting for has occurred, you give an API endpoint to the site you're watching, and they'll send you a request when something interesting happens, containing the information you're interested in.

Ben Halpern • Oct 7 '17

Awesome explanation. I think webhooks have a scary vibe at first, but it's really just an arrangement with some application to send a POST request to some URL. Maybe that's your app, or maybe it's a URL that Slack, for example, gives you so it can post a message in your channel.

It's really not a lot different from any similar transaction within your own app. On dev.to, we have it arranged that any time someone creates a comment, they hit the /comments endpoint with a POST request. If a second app wanted to do something with the comment creation process as well, they'd tell us to also send a request their way when we're done.