Read streams and handle errors

The chat stream uses server-sent events. Your application needs to preserve partial data between network reads and identify complete event boundaries.

Process a stream

Read the event name and data according to the deployed endpoint’s actual response format. Do not assume a TCP or HTTP read delivers exactly one event. Preserve unfinished lines and events across reads, decode text incrementally, and parse JSON only after receiving a complete payload.

The repository emits both named event records and JSON data records in different workflows. The existing API page’s examples need reconciliation with real wire responses before using them as an authoritative parser specification.

Treat completion and failure as separate outcomes. Keep track of each requested model when comparing multiple replies. A transport disconnect does not establish whether the server finished generating or recorded usage.

Handle HTTP errors

Status	Reviewed cause	Response
400	Invalid or unavailable model selection	Discover allowed models and correct the request
401	Invalid, revoked, or expired key	Check credentials and key status
403	Missing required scope	Check the endpoint and key permissions
422	Invalid request shape	Compare the body with the deployed schema
429	API key rate limit exceeded	Respect Retry-After when provided
500	Key validation or service failure	Record the response and retry cautiously if appropriate

Errors can also occur inside an established stream. Handle them instead of displaying a partial answer as successful completion. Avoid automatic repeated retries of a generation request without considering duplicate work and usage.

For a support report, include the endpoint, response status, request identifier if supplied, and a redacted example body. Never include the raw API key.