Reconnections

A live session outlives its WebSocket. If the connection drops (your network, or a server of ours restarting), reconnect to the same URL: the session continues with the same id and the next utterance ids, without lost or repeated transcripts, and its final result covers everything.

With the Gladia SDKs

Nothing to do. The SDKs reconnect to the same URL when the connection closes abnormally, keep every audio chunk until it is acknowledged, and resend the unacknowledged ones.

With your own client

1. Keep acknowledgments on (messages_config.receive_acknowledgments, the default).
2. Keep each audio chunk until an audio_chunk message covers it: data.byte_range[1] is the number of bytes acknowledged since the start of the session. Audio is acknowledged once it is transcribed.
3. When the connection closes with any code other than 1000, reconnect to the same URL within 60 seconds, send the kept chunks first, then continue. Audio already transcribed is recognised and acknowledged again, never transcribed twice.
4. A transcript message in flight when the connection broke is not sent again; the session’s result, its post_final_transcript and your callbacks have it.

Close codes

code	meaning	what to do
1000	the session ended	nothing
1006	the connection was lost	reconnect, resend the unacknowledged audio
1011	the session failed	create a new session
1012	a server is restarting	reconnect at once
4401	the URL is invalid, expired, or the session ended	create a new session

While a dropped session may still resume, GET /v2/live/{id} reports it as processing; once the 60 seconds have passed, done.