Server-Sent Events (SSE)

Server-Sent Events let a server push updates to a client without the client polling. The client makes one GET with Accept: text/event-stream; the server keeps the response open and writes events as they happen, each as a few lines of text with optional id and event fields. Browsers expose it through the EventSource API.

How it works

Each event is data: lines followed by a blank line. If the connection drops, EventSource reconnects automatically and sends the id of the last event it saw in a Last-Event-ID header, so the server can resume from there without gaps. Servers send periodic comment lines as heartbeats to keep proxies from closing idle connections.

The misconception

That WebSockets are always the better choice. SSE is plain HTTP — it passes through proxies and load balancers that block WebSocket upgrades, needs no special server, and reconnects with resume built in. For server-to-client updates such as notifications, progress and feeds, it is usually the simpler tool.

Try it here

GET /streams/v1/events answers as JSON or, with Accept: text/event-stream, as an event stream; send Last-Event-ID to resume after a given event, and POST /streams/v1/events to publish one.

Related

• Event Streams API docs
• What a webhook is

Sources

• HTTP semantics — RFC 9110
• OpenAPI Initiative

Other terms

• Webhook — An HTTP callback the server sends you when something happens, instead of you polling to ask.
• HMAC signature — A keyed hash proving a payload came from someone holding the shared secret and has not been altered.
• Request ID (correlation ID) — A unique identifier attached to a request and its logs, so one call can be traced across every service it touched.

All glossary terms · Testing techniques · All 39 mock REST APIs

Last updated 16 October 2026