REST vs webhooks vs SSE: who initiates, who stays open?

REST is client-initiated, pull-based request/response — the client always asks. Webhooks flip that relationship: the SERVER pushes an event by making an HTTP request to a URL the client registered in advance, which means the "client" must itself run a public server to receive it. SSE (Server-Sent Events) keeps the normal client-initiates-a-connection shape, but leaves that one connection open so the server can push a continuous stream of events over it.

A payment provider is a clean example: you use REST to create a charge (POST /charges), the provider uses a webhook to notify YOUR server the moment that charge settles or fails (server-to-server, asynchronous, could be minutes later), and your server then relays that status update to the customer's open browser tab over SSE so the UI updates live without a manual refresh. None of the three replaces another here — each is doing the specific job it fits.

The distinction that actually explains all three isn't simply "push vs pull" — it's two separate questions: WHO exposes a listening endpoint, and WHETHER the connection between them persists. Webhooks flip the usual client/server relationship entirely: the "client" in this exchange has to run its own public HTTP server to receive the callback, which is why webhook integrations need signature verification (proving the request really came from the sender) and idempotency handling (the sender may retry and send the same event twice) — problems that don't exist for REST, where the caller already trusts its own request. SSE keeps the normal relationship (client connects out to server) but leaves that one connection open indefinitely, which is a different kind of engineering cost: the server now has to hold open one connection per active client, rather than briefly touching a connection pool per request the way REST does.

This is also exactly why picking the wrong one breaks specific things: building "real-time notifications" with REST polling wastes resources checking at a fixed interval regardless of whether anything changed, and gives you staleness up to that interval by design. Trying to use SSE for guaranteed server-to-server delivery (payment or order events) loses out because SSE has no acknowledgment or retry semantics built for that relationship — it's built for pushing to an open UI, not for a durable notification contract between two backends, which is precisely the job webhooks (plus your own retry logic) are built for.

A customer subscribes through your app: a REST call, POST /subscriptions, standard client-initiated request/response — nothing needs to stay open for this. Days later, a payment attached to that subscription fails; your billing provider needs to tell YOUR backend this happened, asynchronously, whenever it occurs — that's a webhook, which means your backend must expose an endpoint, verify the request's signature came from the real provider, and handle the possibility of the same event arriving twice.

Once your backend knows the payment failed, the customer — who happens to have their billing settings tab open right now — should see that status update live, without refreshing. That's SSE: your backend, having received the webhook, pushes the update down the customer's already-open connection. Three different problems (create a subscription, receive an async event from another company's server, push a live update to an open tab), three different tools, none of them interchangeable with either of the others for this job.

Polling asks “anything new?” on a fixed interval; a push (webhook or SSE) sends exactly one message per real update. If you need freshness of P seconds (poll every P) but updates actually arrive every U seconds, you make U/P polls per update and U/P − 1 of them return nothing.