WebSocket & SSE

Two different things that both stream, handled differently because they are different.

WebSocket

A manual connect / send / receive session. You drive it; Tinspec does not replay a script at the socket.

1. Create a request with protocol WebSocket.
2. Set the URL — ws:// or wss://.
3. Connect. The editor’s own controls replace the toolbar’s Send.
4. Compose and send frames while the session is open.
5. Close when done.

Every frame — sent and received — lands in a live log in order, so you can see the conversation rather than just the last message.

Headers set on the request are sent with the opening handshake, and auth injection and {{variable}} resolution apply to the URL and those headers exactly as they do elsewhere: a WebSocket session opens through the same engine path as every other send.

Limits

• No scripted or replay sends. The session is interactive by design.
• Not chainable. A chain step expects exactly one response; a duplex session does not produce one. WebSocket requests appear disabled in the chain request picker.
• The session ends with its editor. Closing the tab drops the connection — a live socket is not restored when you reopen the tab.
• The cookie jar does not apply to WebSocket.

Server-sent events

SSE is not a separate protocol — it is an ordinary HTTP request whose response streams.

Set Accept: text/event-stream on an HTTP request and send it. Tinspec routes it through the streaming path and the response panel renders a growing list of events as they arrive, with a Raw toggle for the unparsed stream.

This is the right tool for a chat completion endpoint, a progress feed, or any long-lived text/event-stream response.

Limits

• Tests are not evaluated on a streaming send. There is no single buffered response for assertions to run against.
• The stream is assembled in the UI as it arrives.

Which one am I looking at?

	WebSocket	SSE
Protocol setting	websocket	http
Direction	Bidirectional	Server → client only
How it starts	You press Connect	An ordinary send
URL scheme	ws:// / wss://	http:// / https://
Chainable	No	No (streaming send)
Cookie jar	No	Yes

If you need bidirectional messaging, use WebSocket. If the server just pushes and you only read, the endpoint is almost certainly SSE and should be sent as HTTP.