Webhook vs Callback: what’s the difference?

A callback is a function you hand to other code so it can run it later, inside a single program. A webhook is an HTTP request one service sends another when an event happens. Both are ways of saying “tell me when this is done,” but a callback stays in your process and a webhook crosses the network.

Sending webhooks?

Svix is the enterprise-ready webhook sending service. It handles signing, retries, and delivery observability, so you can ship a reliable webhook platform in minutes instead of months. Start sending webhooks with Svix.

What a webhook does

Webhooks are a method of communication between two applications or services, where one service sends an HTTP request to another when a specific event occurs. The receiving service, also known as the subscriber, registers a webhook endpoint that listens for incoming requests. Webhooks are often used in event-driven architectures and are an efficient way to keep systems in sync, as they enable real-time updates and notifications.

What a callback does

Callbacks, on the other hand, are functions that are passed as arguments to another function and are executed at a later time or upon the completion of a specific task. In the context of programming, callbacks are often used for asynchronous operations, such as handling the response from an API request or processing user input in a graphical user interface.

The two meanings of “callback”

The word carries a second, unrelated sense that causes most of the confusion here. In OAuth flows and payment redirects, a “callback” means a callback URL: an address you register with a provider so it can send the user, or a one-off result, back to you over HTTP. That kind of callback is much closer to a webhook than to a language-level callback function. The practical difference is scope and lifetime. A callback URL usually completes one transaction for one user and then stops mattering; a webhook endpoint is a standing subscription that keeps receiving events for as long as it is registered.

How they compare

Both webhooks and callbacks handle events, and both involve one component telling another that something changed. The differences that matter in practice:

1. Communication method: Webhooks use HTTP requests for communication between services, whereas callbacks involve passing a function as an argument within the same application or programming environment.
2. Scope: Webhooks are generally used for communication between separate applications or services, often across different domains or environments. Callbacks are used within a single application or environment, usually for managing asynchronous operations or handling user interactions.
3. Language and platform: Webhooks are language-agnostic and can be used for communication between services written in different programming languages or running on different platforms. Callbacks are typically language-specific, as they involve passing a function within the same programming environment.
4. Failure handling: A callback either runs or it does not, and the surrounding code sees the error immediately. A webhook can fail on the wire, so the sender owns a retry policy and the receiver has to expect duplicates.

Choosing between them

If both pieces of code run in the same process, you want a callback: it is faster, simpler, and the error path is visible to the caller. If the two sides are separate services, especially across an organizational boundary, you want a webhook, and with it the delivery concerns a network hop brings. [Svix]https://www.svix.com/?utm_source=resources&utm_medium=content) handles that side for teams sending webhooks to their own users, with signatures, retries, and delivery logs built in.