Server-Sent Events

Open an event stream and read each event as the server sends it, with automatic reconnecting.

What Server-Sent Events are

Server-Sent Events (SSE) is a way for a server to keep an HTTP response open and push text events down it, one after another. The traffic goes one way only: from the server to the client. Live dashboards, notifications and streaming chat completions use it.

A stream is a normal http:// or https:// URL whose response has the type text/event-stream. Each event can carry:

• data: the content.
• event: a name. Events without one are named message.
• id: a marker the client sends back when it reconnects, so the server can continue where it stopped.
• retry: how long the client should wait before reconnecting, in milliseconds.

Open your first stream

This example uses https://postman-echo.com/server-events/5, a public test address that sends five events and then ends the stream.

1. In the tab bar, select the small arrow next to + and choose Server-Sent Events.

   A tab named New SSE opens with https:// in the URL field.

2. Type https://postman-echo.com/server-events/5 in the URL field.

3. Open the Settings tab and turn off Reconnect automatically.

   This test stream ends after five events. With reconnecting on, the app would open it again and again.

4. Select Start, or press Enter in the URL field.

   The status changes from Stopped to Connected. The log lists each event with its name, id and data. The line above the log shows the response status, for example HTTP 200.

5. When the server ends the stream, the log says so and the status returns to Stopped. To end a stream yourself, select Stop.

GET or POST

Use the method menu next to the URL.

• GET opens the stream with a plain request. This is the usual choice.
• POST sends a body first. Some streaming APIs, such as chat completion endpoints, require it.

Write the POST body on the Body tab. A JSON body is sent with Content-Type: application/json unless you set that header yourself. If the method is still GET, the tab offers Use POST.

Params and headers

• Params are added to the end of the URL.
• Headers are sent with the request, for example Authorization: Bearer {{token}}. Accept: text/event-stream is added for you.

Variables are filled in when you start the stream.

Stream settings

Setting	What it does	Default
Reconnect automatically	After the stream ends or fails, wait and connect again, sending the last event id in the Last-Event-ID header. Stop cancels it.	On
Default retry (ms)	The wait before reconnecting, until the server sets its own with a retry: line.	3000
Reconnects before giving up	Reconnects in a row before stopping. A successful connection resets the count. 0 keeps trying.	0
Show comment lines	Lists lines that start with :, which servers send as keep-alives. They are hidden otherwise.	Off

A response with any status other than 200 is never retried. The log shows the status and the start of the response body, so you can see why the server refused.

If the response is not text/event-stream, the log says so and the events are parsed anyway.

Streams follow the app's Verify TLS certificates setting, the proxy and the extra CA certificate. See Proxy and certificates.

The message log

The line above the log shows the latest response status, the id of the last event received and the current reconnect wait, for example HTTP 200 · last id 42 · retry 3000 ms.

The log itself works like the WebSocket log: search, filter, copy and clear. See Read the message log.

Next steps

• WebSocket
• gRPC
• Headers