Streaming Responses with SSE: A Practical Walkthrough

A streaming response is not simply a completed answer delivered in smaller pieces. Your application needs boundaries, lifecycle states, and a clear distinction between partial output and successful completion. Use this numbered walkthrough to build an implementation that remains understandable when connections fail.

1. Define the streaming contract

Start by documenting the request format, event schema, and completion signal. SSE uses the text/event-stream media type, UTF-8 encoding, and blank lines to separate events. Transport chunks are not application messages: one network read can contain part of an event or several events. ([html.spec.whatwg.org](https://html.spec.whatwg.org/multipage/server-sent-events.html?utm_source=openai))

For an integration through CodeRelay Hub, keep routing configuration separate from stream handling. Build your application around the endpoint contract you actually use, rather than assuming every upstream model exposes identical streaming fields. Record which features your selected route supports before enabling optional parameters.

2. Choose the right client transport

The native EventSource interface accepts a URL and an optional credentials setting, but it does not expose a request body or arbitrary request headers. For a generation request that requires POST and bearer authentication, use fetch with a streaming response reader, or an SDK that handles the transport. ([html.spec.whatwg.org](https://html.spec.whatwg.org/multipage/server-sent-events.html?utm_source=openai))

Keep API credentials on your backend. Have the browser call your application, then let your server authenticate the upstream request. Check the upstream HTTP status and content type before forwarding streaming headers, so an authentication failure becomes a useful error instead of an unexplained empty stream.

3. Parse events, not network reads

Use an incremental UTF-8 decoder and retain unfinished text between reads. Process complete lines while preserving any trailing fragment. Recognize LF, CRLF, and CR line endings, and handle a CRLF pair split across reads without creating a false blank line. These are valid SSE line-ending forms. ([html.spec.whatwg.org](https://html.spec.whatwg.org/multipage/server-sent-events.html?utm_source=openai))

Collect data fields until the terminating blank line, join multiple data values with newline characters, and only then parse the application payload. Ignore comment lines beginning with a colon. Do not dispatch an unfinished event merely because the connection closes; SSE requires the event boundary. Prefer a tested parser over a quick split operation. ([html.spec.whatwg.org](https://html.spec.whatwg.org/multipage/server-sent-events.html?utm_source=openai))

4. Accumulate deltas deliberately

For OpenAI-style Chat Completions streams, inspect choices[0].delta rather than expecting a complete message object. A delta can contain a role, content, or no content at all. Append only content that is actually present, and keep metadata separate from the displayed answer. ([developers.openai.com](https://developers.openai.com/api/docs/guides/streaming-responses?utm_source=openai))

If your application supports tool calls, accumulate their arguments separately from visible text. Do not execute a tool from an incomplete argument fragment. Batch interface updates on a short rendering cadence instead of rebuilding the entire conversation for every fragment, and treat generated content as untrusted when rendering it.

5. Make completion explicit

Track connecting, streaming, completed, cancelled, and failed states. Mark success only after the documented completion condition; a closed socket alone should not imply success. Preserve partial output after interruption, but label it incomplete and offer a deliberate retry action.

Where supported, request usage with stream_options: {"include_usage": true}. OpenAI documents an additional usage chunk before the terminal marker, with an empty choices array. An interrupted stream might never deliver that chunk, so do not record missing usage as zero. Verify support on your selected route. ([developers.openai.com](https://developers.openai.com/api/reference/resources/chat/subresources/completions/streaming-events?utm_source=openai))

6. Handle cancellation and slow consumers

Connect a Stop button to an AbortController, and propagate browser disconnects to the upstream request. Set separate limits for establishing a connection and waiting between events. Bound pending output, honor downstream backpressure, and test proxy buffering before production. Avoid silently retrying after displaying text: require an explicit restart unless your application implements a documented resume protocol.

7. Test failures before shipping

Test split Unicode characters, fragmented event boundaries, multiple events per read, empty deltas, malformed payloads, cancellation, and disconnects before completion. Log request identifiers and lifecycle timestamps without storing sensitive prompts by default. Measure first visible content separately from total completion time, and make incomplete responses visible in operational dashboards.

Open a free CodeRelay Hub workspace to get started.