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 — text, or binary written as hex.
5. Disconnect 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. Ping and pong frames are answered automatically and are not shown; they are plumbing, not conversation.

Auth and variables

Headers set on the request are sent with the opening handshake, and {{variable}} resolution applies to the URL and those headers. Auth works the same way it does elsewhere: an auth provider (optionally with a sender), or an inline credential held in the OS keychain, and a per-request Inject as override if this one socket wants the token somewhere other than where the provider normally puts it.

The one injection target WebSocket does not offer is body — there is no request body for a handshake to put it in. Header, query, cookie and variable-only all apply.

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, and the engine refuses them at run time too, naming the node.
• The session is ephemeral. It is not part of the saved request — nothing about a live socket is written to the collection file, and nothing reconnects it for you.
• The cookie jar does not apply to WebSocket.
• Layered send settings do not reach the handshake. A WebSocket session is opened without them, so a proxy, a client certificate, a custom CA bundle or Allow insecure TLS configured for the surrounding collection, provider or globally has no effect on a wss:// connect. A self-signed development socket therefore fails on certificate validation, and the toggle that rescues an HTTPS request does not rescue this one.

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. The detection is the Accept header and nothing else; Settings → Editor & response → Auto-stream SSE turns it off if you would rather buffer.

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

What a streaming send does not check

A stream has no single buffered response, and three checks quietly depend on there being one. Rather than let a run look clean when nothing ran, the response panel lists them out loud — Not checked on a streaming send: 3 request tests, contract drift, the post-request script.

Skipped	Why
Request tests	There is no one response for the assertions to run against
Contract drift	Diffing a bound endpoint over an unbounded event stream is a different feature, not a missing branch
The post hook	A post-request script reads a response; a stream never hands it one
The pre hook’s log output	The hook itself does run — a signature still reaches the wire — but its console lines have nothing to hang on

There is no Timeline tab on a streaming response either: phase timings are collected only for buffered HTTP sends.

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
Layered send settings	No	Yes
Request tests	No	No

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.