Webhooks vs APIs vs WebSockets: What's the Difference?

An API is pull. Your app asks, and the server answers, once, then the connection closes. A webhook is push too, but still one-shot. The provider sends a single HTTP call the moment an event happens. A WebSocket is push too, but it stays open. One long-lived connection. Either side can send a message at any time, for as long as it lasts. The real split isn't just push versus pull. It's whether the connection survives past one message.

The three models, side by side

Picture a chat app to see the difference. Loading old messages on page load is a pull: one request, one response, done. A new message arriving from someone else is a push. Whether that push is a webhook or a WebSocket depends on two things. How often it happens. How fast it needs to land.

• API (REST): your app asks, the server answers, the connection closes. Fits anything you control the timing of.
• Webhook: the provider calls your endpoint once, when an event happens. No connection stays open between events.
• WebSocket: one connection stays open. Both sides send messages over it whenever they want. No new handshake per message.

Why a webhook and a WebSocket aren't the same kind of push

Both notify you without polling. Both get called "real-time" in casual talk. The difference that actually matters is connection lifetime.

A webhook is a plain HTTP POST. It opens a connection, sends one payload, and closes it, the same as any other API call. Your server doesn't need to hold anything open between events. That's why a webhook handler runs fine as a stateless serverless function. Nothing to keep alive. No state to lose on a cold start.

A WebSocket needs a connection that survives for the life of the session, sometimes hours. Something has to hold that connection open the whole time. On plain serverless setups, like a Lambda that exits after it returns, that's a real design problem. Not a small detail. Running WebSockets on Lambda takes a managed layer built for it, like API Gateway's WebSocket support. A bare Lambda invocation ends the moment it returns. It can't hold a socket open on its own.

When each one is the right call

Reach for an API when your app decides when to ask. A page load, a search query, a nightly sync: pull fits anything on your own clock.

Reach for a webhook when you need to react to discrete events. A few hundred milliseconds of delivery lag won't matter here. A payment succeeding, a pull request opening, a file finishing an upload. One event, one HTTP call, done.

Reach for a WebSocket when both sides need to talk continuously. The gap between an event and your reaction has to stay small. A live chat thread. A multiplayer cursor position. A collaborative editor showing another user's keystrokes as they type. Anything where "check back in a second" is too slow. A one-shot HTTP call per keystroke would mean opening and closing thousands of connections a minute.

The mistake: picking WebSockets by default for "real-time"

"Real-time" gets used to justify a WebSocket a lot. Often the real need is just this: notify me within a few seconds of an event. A webhook already covers that. A WebSocket buys you sub-second, bidirectional messaging. It also buys you a connection to keep alive. Reconnect logic for drops. Scaling across every server that might hold one open. That's a real infrastructure cost, not a free upgrade over a webhook.

Say the real need is just this: tell my backend when X happens. A webhook does that, no connection to manage. Save the WebSocket for when the client needs to send and receive on the same open channel. Not just receive a notice.

What happens when a WebSocket connection drops

A dropped WebSocket fails in a different way than a failed webhook or API call. An API call that fails just gets retried on the next request. A webhook that fails gets retried by the provider on its own schedule. The event ID is the safety net against duplicates.

A dropped WebSocket loses whatever the client missed while it was offline. Unless something on the server replays it. That replay logic doesn't come free. The server has to track what each client already saw. Or the client re-fetches state through a regular API call the moment it reconnects. A chat app usually does both. WebSocket for new messages while connected. A REST call to backfill anything missed on reconnect.

Where Draftbase fits

Draftbase fires a webhook on every entry event: created, updated, published, archived. That's a one-shot event notification. It's the right shape for triggering a rebuild, or syncing a search index, the moment an editor publishes. No persistent connection for your infrastructure to manage. See what a webhook is for how that delivery model works. Or read how to create and test a webhook to wire one up. For pulling content on your own schedule, the delivery API covers the request-response side of this comparison.