Skip to main content

Server-Sent Events (SSE)

Rostyman supports Server-Sent Events for testing streaming APIs that push real-time updates from the server over a persistent HTTP connection. SSE is commonly used for live notifications, log tailing, price feeds, progress updates, and AI/LLM streaming completions.

What is SSE?

Server-Sent Events (SSE) is a W3C standard protocol built on top of plain HTTP. Unlike WebSocket, SSE is unidirectional — the server pushes a stream of events to the client, but the client does not send messages back over the same connection. The client makes a single HTTP request and the server responds with Content-Type: text/event-stream, keeping the connection open and writing events as they occur.

Each event in the stream is a block of plain text in the format:

id: 42
event: message_delta
data: {"type":"content_block_delta","delta":{"text":"Hello"}}

Fields:

FieldDescription
idOptional event identifier. Browsers use this for reconnection (Last-Event-ID).
eventOptional event type name. Defaults to message if omitted.
dataThe event payload. May be a plain string or JSON. Can span multiple data: lines.

Events are separated by a blank line. The connection stays open between events.


Two ways to use SSE

Rostyman gives you two ways to work with Server-Sent Events, both feeding the same live event log:

  • A dedicated SSE request — a first-class request type (like WebSocket or MQTT) with its own tab and a persistent Connect / Disconnect lifecycle. Best for long-lived or never-ending streams you want to save and re-run.
  • Auto-detected on any HTTP request — send a normal request; if the response is Content-Type: text/event-stream, the response panel switches to the event log automatically. Best for quick, ad-hoc checks and finite streams.

Creating a dedicated SSE request

Step 1 — Open an SSE tab

Create a request and choose SSE as the protocol — from the New Request dialog, the + new-tab menu, or right-click a collection → Add Request → SSE. The tab shows an SSE badge with a connection-status dot.

Pick GET or POST with the method selector (a Body sub-tab appears for POST), enter the endpoint URL, and add any Params / Headers you need. The transport always sends Accept: text/event-stream, Cache-Control: no-cache, and Connection: keep-alive for you (shown as read-only auto-headers); tune SSL verification and the connection timeout in the Settings sub-tab. Environment variables ({{variable}}) work everywhere.

Step 2 — Connect

Click Connect to open the stream. Events arrive in the event log live as the server pushes them, and a timer shows how long the connection has been open. Click Disconnect (the same button) to close it.

Save the request into a collection with Ctrl+S — the method, URL, params, headers, and body are all persisted. (The event log itself is session-only.)

Auto-detecting SSE on an HTTP request

You can also stream SSE from a plain HTTP request without choosing the SSE type — handy for AI endpoints where "stream": true in the body triggers an event-stream response.

Step 1 — Create an HTTP Request

Open a new HTTP request tab. SSE works with both GET and POST:

  • GET — the standard SSE method. Most SSE endpoints accept a plain GET request.
  • POST — used by some APIs (particularly AI/LLM services) that accept a request body and return a streaming response.

Step 2 — Set the URL

Enter the SSE endpoint URL in the URL bar:

GET https://api.example.com/events
GET https://api.example.com/logs?level=info
POST https://api.openai.com/v1/chat/completions

Environment variables ({{variable}}) work in the URL, headers, and body.

Step 3 — Configure Headers

Add headers in the Headers tab as you would for any HTTP request.

For SSE, the most important header is:

HeaderValueWhen to use
Accepttext/event-streamAlways recommended for GET SSE endpoints — tells the server you want an event stream
AuthorizationBearer {{api_key}}Required by most protected APIs
Content-Typeapplication/jsonRequired when sending a POST body
Cache-Controlno-cacheSome SSE endpoints require this

Step 4 — Configure the Body (POST only)

For POST requests that return SSE streams (common with AI APIs), add a JSON body in the Body tab:

{
"model": "claude-3-5-sonnet-20241022",
"messages": [
{ "role": "user", "content": "Explain quantum entanglement" }
],
"stream": true,
"max_tokens": 1024
}

The "stream": true field is recognized by many AI APIs as the signal to return an SSE stream instead of a regular JSON response.

Step 5 — Send the Request

Click Send (or press Ctrl+Enter). Rostyman sends the HTTP request and monitors the response.

When the response has Content-Type: text/event-stream, the response panel automatically switches to the SSE Event Log view. Events appear in the log as they stream in from the server.


SSE Event Log

The event log is the live response panel for SSE streams. Events are displayed in reverse chronological order (newest at top) so the most recent events are always visible without scrolling.

Connection Lifecycle Entries

Two system entries frame the event stream:

EntryPositionDescription
Connected to <url>Bottom of logShown when the stream opens, with a timestamp
Connection closedTop of logShown when the stream ends (server closed or you clicked Close)

Event Rows

Each event row shows:

ElementDescription
Direction arrow (↓)Indicates an incoming server-pushed event
Event type badgeColor-coded label showing the event: field value (e.g., message, ping, content_block_delta)
Data previewTruncated first line of the event's data field
Info icon (ⓘ)Hover to see the event size in bytes. Visible only on row hover.
TimestampHH:MM:SS.mmm (millisecond precision) when the event was received

Expanding an Event

Click any event row to expand it. The expanded view shows the full event data in a Monaco editor:

  • JSON syntax highlighting with line numbers and code folding
  • JSON / Text toggle — switch between formatted JSON view and raw text view
  • Beautify button — re-formats the JSON with 2-space indentation
  • Copy button — copies the full event data to the clipboard
  • Search (Ctrl+F inside the editor) — search within the expanded content

Click the row again to collapse it.

Event Type Badge Colors

Badge colors are theme-aware (light and dark themes use different shades for legibility):

Event TypeColor
message_start, content_block_startGreen
message_stop, content_block_stop, errorRed
message_delta, content_block_deltaOrange
messageBlue
pingGray
Other / unknownNeutral gray

Event Count

The log toolbar shows the count of real data events received (connection status entries are excluded from the count).

Search and Filter

A search box in the event log toolbar filters events in real time. Typing filters by event type name or data content (case-insensitive). The event count updates to reflect the filtered set.


Stopping a Stream

On a dedicated SSE request, click Disconnect to end the stream. On an auto-detected HTTP stream, the Send button changes to Close (or use the cancel button). Click to end the stream.

The connection also closes automatically when:

  • The server closes the stream (sends an empty event or closes the TCP connection)
  • A network error occurs

After the stream closes, the event log remains visible with all events captured during the session. The Connection closed entry appears at the top.


History Integration

When an SSE stream closes (either by you or the server), the request is automatically saved to the History panel. The history entry includes:

  • The request URL, method, and headers
  • Total response time
  • Total body size (sum of all event data)
  • All event data received during the session

You can open a history entry to replay the same SSE request.


Saving to a Collection

SSE requests are saved to collections exactly like regular HTTP requests — press Ctrl+S (or Cmd+S on macOS).

What is persisted:

  • URL
  • HTTP method (GET or POST)
  • Headers (including Accept: text/event-stream)
  • Request body (for POST streams)
  • Environment variable references ({{variable}})

The event log is session-only and is not saved.


Common SSE Patterns

Basic GET Stream

GET https://api.example.com/events
Accept: text/event-stream
Authorization: Bearer {{api_key}}

OpenAI-style Streaming Completion

POST https://api.openai.com/v1/chat/completions
Authorization: Bearer {{openai_key}}
Content-Type: application/json

{
"model": "gpt-4o",
"messages": [{"role": "user", "content": "Hello"}],
"stream": true
}

Anthropic Claude Streaming

POST https://api.anthropic.com/v1/messages
Authorization: Bearer {{anthropic_key}}
anthropic-version: 2023-06-01
Content-Type: application/json

{
"model": "claude-3-5-sonnet-20241022",
"messages": [{"role": "user", "content": "Hello"}],
"max_tokens": 1024,
"stream": true
}

Tips

  • SSE is one-way — if you need to send messages back to the server after the connection opens, use WebSocket or Socket.IO instead
  • For AI APIs, the "stream": true field in the POST body is the standard way to request SSE output — you do not need to set Accept: text/event-stream separately for most AI providers, though adding it does not hurt
  • Store API keys and base URLs in environments and use {{variable}} in headers and the URL — switch between providers or accounts without editing requests
  • The millisecond-precision timestamps in the event log are useful for measuring streaming latency — how long after the request the first event arrives, and gaps between events
  • Use the search box to find specific event types in a long stream — for example, search for error to quickly find any error events in a long AI response stream