Server-Sent Events (SSE) is a WHATWG-standardized mechanism for servers to push a stream of text-based events to clients over a single long-lived HTTP connection. The browser EventSource API consumes the text/event-stream media type with automatic reconnection.
Server-Sent Events
Server-Sent Events (SSE) is a WHATWG-standardized way for a server to push a continuous stream of text events to a client over a single long-lived HTTP connection. The client opens an EventSource, the server responds with the text/event-stream media type, and events flow one direction — server to client — until either side closes. It is the quiet, HTTP-native answer to real-time updates that does not require the ceremony of WebSockets.
- One-way streaming over HTTP - Events flow server-to-client on an ordinary HTTP connection, so it works through the same infrastructure your APIs already use.
- The EventSource API - Browsers consume the stream with a small, standard JavaScript client that needs no extra library.
- Automatic reconnection - The protocol builds in retry and a
Last-Event-IDso a dropped connection resumes without custom plumbing. - Plain-text framing - The
text/event-streamformat is human-readable and trivial to produce, which keeps servers simple.
In API operations SSE shines wherever a client needs a live feed but not a full duplex channel — progress on a long-running job, a notification stream, or incremental results. It is having a real moment in the agentic turn: streaming token-by-token model output and remote MCP transports lean on SSE precisely because it is HTTP-native and firewall-friendly. When one-way push is all you need, reaching for SSE over heavier WebSockets keeps the whole stack closer to the web it already runs on.
Referenced on the API Evangelist blog
Where this standard shows up across sixteen years of my writing at apievangelist.com — how it fits into API design, governance, and the agentic turn.
