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.

---

Using SSE in Rostyman

SSE is not a separate tab type — it uses the standard HTTP request tab. Rostyman detects text/event-stream responses automatically and switches the response panel from the standard body view to the live event log view.

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

While an SSE stream is active, the Send button changes to Close. Click it 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