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:
| Field | Description |
|---|---|
id | Optional event identifier. Browsers use this for reconnection (Last-Event-ID). |
event | Optional event type name. Defaults to message if omitted. |
data | The 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:
| Header | Value | When to use |
|---|---|---|
Accept | text/event-stream | Always recommended for GET SSE endpoints — tells the server you want an event stream |
Authorization | Bearer {{api_key}} | Required by most protected APIs |
Content-Type | application/json | Required when sending a POST body |
Cache-Control | no-cache | Some 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:
| Entry | Position | Description |
|---|---|---|
Connected to <url> | Bottom of log | Shown when the stream opens, with a timestamp |
| Connection closed | Top of log | Shown when the stream ends (server closed or you clicked Close) |
Event Rows
Each event row shows:
| Element | Description |
|---|---|
| Direction arrow (↓) | Indicates an incoming server-pushed event |
| Event type badge | Color-coded label showing the event: field value (e.g., message, ping, content_block_delta) |
| Data preview | Truncated first line of the event's data field |
| Info icon (ⓘ) | Hover to see the event size in bytes. Visible only on row hover. |
| Timestamp | HH: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 Type | Color |
|---|---|
message_start, content_block_start | Green |
message_stop, content_block_stop, error | Red |
message_delta, content_block_delta | Orange |
message | Blue |
ping | Gray |
| Other / unknown | Neutral 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": truefield in the POST body is the standard way to request SSE output — you do not need to setAccept: text/event-streamseparately 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
errorto quickly find any error events in a long AI response stream