Webhooks are for server to server communication. They work by one server telling another server that it wants data sent to a certain url when something happens.

This article talks about some uses of webhooks in popular services. This organization talks a lot about using them in the context of RESTful APIs.

webhooks are simply a pattern for an evented web. All they are is a promise by an application or API: “when this thing happens, I’ll send this HTTP request with this data.” That simple promise opens up a lot of opportunities, though. It enables the web to start being aware of events, to respond to things without user interaction. It makes the web capable of pushing information to its users, instead of waiting for users to ask for information. Webhooks are “user-defined HTTP callbacks”.


Websockets are (usually) for server to browser communication. The server hosts a websocket server, and clients can open a connection to that server. This is popular now mostly because it is faster and less resource-hogging than older ways of solving the problem, like long-polling/COMET.

  • It is possible to connect 2 servers using websockets, but that is not usually what they are used for.

  • WebSockets allow your client-side JavaScript to open and persist a connection to a server.

The confusion

Even though one of these is (exclusively) server-server and one is (mostly) browser-server, these technologies are often discussed in the same places, almost like they are solving the same problems. If you look up the chain high enough, you see that they both solve the problem of “real time” communication, but they solve different aspects of this problem in very different ways.

One situation where there may be a direct comparison if if you are building an API that will be consumed by a third party server. In that situation, you could provide a webhook API or a websocket API. Both allow the third party to get updates quickly, but if you choose webhooks that third party will still have to figure out a way to push the changes you are telling them about to their client’s browsers. If you provide a websocket API, the third party can just set up their site so each of their users connect directly to your websocket API, and their servers have to do less work.

From Webhooks to the Evented Web

Back in 2007 I started thinking and talking a lot about an idea called webhooks. Over the following few years I started evangelizing it. I spent a lot of my free time giving talks and building tools around the idea of webhooks. Some of these tools are still around today, including Localtunnel and RequestBin (originally PostBin). There were others that might not be around anymore: MailHooks, ClickHooks, TwitterHooks, Scriptlets, and a few others.

Webhooks wasn’t really a new technology in the sense that there was a specification or tangible piece of software. It was more of an architectural pattern

Moving Data over the Web: AJAX vs. WebSockets vs. Webhooks


AJAX allows your client-side JavaScript application to make a request to access a server-side resource. One nice thing about AJAX is that it won’t hold up your app while waiting for the response (i.e. it’s non-blocking). Instead, when the response is ready, a ‘callback’ function will be invoked to process the request. This was pretty awesome a decade ago and is still very relevant today. Here is an example of a simple coordinate-pair reprojection service that uses AJAX to send requests to FME Server’s Data Streaming service.