Skip to main content
for real-time playback, mint a one-shot websocket session, connect to it, and send a json frame with your synthesis parameters. when audio_format is omitted, the server streams raw pcm int16 little-endian @ 24 khz mono as binary frames, then a terminal {"type":"done"} json text frame.
1

mint a session

POST /v1/tts/ws-connect returns { ws_url, token, request_id, expires_in }. the token is single-use and expires in 300 seconds (expires_in).
2

connect and send

connect to ws_url?token=<token> and send one json synthesis frame.
3

collect pcm

read binary pcm chunks until the done (or error) control frame.

choose an audio format

add audio_format to the post /v1/tts/ws-connect body to stream opus, pcm, mulaw, alaw, or mp3. the format is fixed for that one-shot session, so do not repeat it in the synthesis frame. always connect to the returned ws_url.
curl
see audio formats for exact content types, file extensions, and a complete websocket example.
never put a rk_live_ key in a browser. call /v1/tts/ws-connect from your server and pass only the returned ws_url and token to the page. the token is single-use and expires in 5 minutes. the browser example below does this: the page asks your own endpoint (here /tts-session) for a session.

interruption (barge-in)

for a live “call with ai”, keep the websocket open for the whole call and send a new {"text": "..."} frame for each thing the agent says. if the caller talks over the agent, just send the next utterance: a new text frame while one is still generating interrupts the current one and starts the new one. this is “latest-wins”, there is no special barge-in frame.

frames

once connected, the session is a two-way stream of json text frames and binary audio. client → server server → client on a barge-in you receive {"type": "cancelled", "reason": "interrupt"} for the old request, then the audio chunks and done for the new one. the old audio stops almost immediately.

errors

an error frame ends the current generation, so stop waiting for done when you see one.
POST /v1/tts/ws-connect shares POST /v1/tts’s UNSUPPORTED_AUDIO_FORMAT (400) and VALIDATION_ERROR (422), but not INVALID_TEXT: the mint does not check the text, the socket does, as the frame above. see quickstart.

behavior

  • latest-wins: only the newest utterance is held. a burst of requests during one generation never queues a backlog of now-stale audio, only the latest runs next.
  • immediate stop: on interrupt or cancel the old audio stops streaming right away, so the caller stops hearing it within a couple hundred milliseconds (mostly network round-trip).

example

python