Skip to main content
KugelAudio TTS endpoints return the same error shape for HTTP responses and WebSocket error frames.
retry_after is not included in the JSON body. When retry timing is available for an HTTP response, use the Retry-After response header.

HTTP and WebSocket payloads

WebSocket close codes

WebSocket error frames use the same JSON payload shape as HTTP errors. If the server closes the socket after sending an error, the WebSocket close code is separate from the JSON code. Close codes 1012 and 1013 are not failures of your request. During a rolling deploy each replica finishes the turn it is generating, then closes idle sockets with 1012; a socket that was mid-turn receives its session_closed event first. Audio you already received is complete up to the last chunk. A handshake against a draining replica is accepted and immediately closed with 1013, so browser and server-side WebSocket clients receive the same portable restart signal. The SDK retry delay defaults to one second. The Python and JavaScript SDKs absorb this for you. If no audio for the current turn has been delivered yet, they wait for the restart retry delay, reconnect to another replica, resend the turn (session config and open contexts included) and keep streaming, so a deploy is invisible to your users. Nothing is replayed once audio has started, because that would repeat what the listener already heard, and no turn is replayed twice. In those two cases the SDK raises the retryable ServerRestartingError and you decide what to resend. The JavaScript SDK also offers an onServerRestart callback for observing the silent replays; the Python SDK logs them at INFO on the kugelaudio.streaming logger.

Handling errors

Use error_code and code for application logic. Treat error as display text only.