Live transcript (update event) never fires under v3 gateway transport

Support Help
1

Summary: After migrating from /v2/create-web-call to /v3/create-web-call (per your Sep 30, 2026 deprecation notice) and upgrading retell-client-js-sdk from 2.0.7 → 3.0.1 accordingly, the browser’s "update" event (which carries live transcript data via RetellWebClient) never fires — not once, across multiple full calls — even though the call connects, audio flows correctly in both directions, and the call completes and gets scored normally afterward.

Environment:

  • retell-client-js-sdk@3.0.1
  • v3 /create-web-call response for these calls: "transport": "gateway" (per your docs, this is the only value this endpoint returns — no request parameter exists to select “livekit” instead)
  • Using the legacy-compatible RetellWebClient class (still exported from the package for backward compatibility)

Evidence this is real and reproducible, not a one-off:

  1. Call ID call_995d2775aa7a46d235cea8f71c1 (52 seconds) — public_log confirms 2 full response cycles (response_id 3 and 5) with normal ASR/LLM/TTS latency breakdowns, spread across the actual call duration — server-side generation is unambiguously live and working correctly.
  2. Client-side: client.on("update", ...) was instrumented with a console log and the browser console’s own filter (searching the complete buffer, not just visible/scrolled entries) shows zero matches for the entire call. The event never fires.
  3. Audio and connection work normally — confirming the underlying RTCPeerConnection/ICE negotiation succeeds; only the separate data channel path (which carries transcript/update events) appears affected.

Root cause traced in your own compiled SDK (retell-client-js-sdk@3.0.1, gateway transport, dist/index.js):

e.onmessage = function(e) {
  try { t.onData(JSON.parse(e.data)) }
  catch(t) {}   // any parse failure is silently swallowed, no error surfaced anywhere
}

If a data channel message fails to parse for any reason (encoding mismatch, unexpected format, etc.), it’s discarded with zero visibility — no error event, no console output. That would produce exactly the symptom observed: a fully working call with a completely silent, invisible transcript failure.

What I could not verify myself: whether messages are actually being sent by your server over this call’s data channel and are failing to parse, or never being sent at all. I don’t have access to wire-level data-channel logs from the client side.

Ask: Could you check server-side logging for call call_995d2775aa7a46d235cea8f71c1 to confirm whether data-channel transcript/update messages were sent during the call, and in what format? This looks like a genuine bug in the “gateway” transport path of retell-client-js-sdk@3.0.1 specifically.

2

Summary: After migrating from /v2/create-web-call to /v3/create-web-call (per your Sep 30, 2026 deprecation notice) and upgrading retell-client-js-sdk from 2.0.7 → 3.0.1 accordingly, the browser’s "update" event (which carries live transcript data via RetellWebClient) never fires — not once, across multiple full calls — even though the call connects, audio flows correctly in both directions, and the call completes and gets scored normally afterward.

Environment:

  • retell-client-js-sdk@3.0.1
  • v3 /create-web-call response for these calls: "transport": "gateway" (per your docs, this is the only value this endpoint returns — no request parameter exists to select “livekit” instead)
  • Using the legacy-compatible RetellWebClient class (still exported from the package for backward compatibility)

Evidence this is real and reproducible, not a one-off:

  1. Call ID call_995d2775aa7a46d235cea8f71c1 (52 seconds) — public_log confirms 2 full response cycles (response_id 3 and 5) with normal ASR/LLM/TTS latency breakdowns, spread across the actual call duration — server-side generation is unambiguously live and working correctly.
  2. Client-side: client.on("update", ...) was instrumented with a console log and the browser console’s own filter (searching the complete buffer, not just visible/scrolled entries) shows zero matches for the entire call. The event never fires.
  3. Audio and connection work normally — confirming the underlying RTCPeerConnection/ICE negotiation succeeds; only the separate data channel path (which carries transcript/update events) appears affected.

Root cause traced in your own compiled SDK (retell-client-js-sdk@3.0.1, gateway transport, dist/index.js):

e.onmessage = function(e) {
  try { t.onData(JSON.parse(e.data)) }
  catch(t) {}   // any parse failure is silently swallowed, no error surfaced anywhere
}

If a data channel message fails to parse for any reason (encoding mismatch, unexpected format, etc.), it’s discarded with zero visibility — no error event, no console output. That would produce exactly the symptom observed: a fully working call with a completely silent, invisible transcript failure.

What I could not verify myself: whether messages are actually being sent by your server over this call’s data channel and are failing to parse, or never being sent at all. I don’t have access to wire-level data-channel logs from the client side.

Ask: Could you check server-side logging for call call_995d2775aa7a46d235cea8f71c1 to confirm whether data-channel transcript/update messages were sent during the call, and in what format? This looks like a genuine bug in the “gateway” transport path of retell-client-js-sdk@3.0.1 specifically.

Update — retracting the client-side theory below, replacing with verified data:

I initially suspected the try/catch shown below was the cause. I’ve since checked the actual data-channel stats directly via chrome://webrtc-internals on a fresh call, at two points ~31 seconds apart while the call was genuinely active (audio RTP continuously flowing normally):

  • data-channel (label=control, state=open): bytesReceived: 37, messagesReceived: 1 at both checks — unchanged the entire call.

This rules out the parse-failure theory — there’s no stream of messages failing silently; there’s only ever one small message the whole call, and it never increases. I don’t know why, and I’m not asserting a new root cause — I can’t see server-side into why only one message is sent. Reporting the measured data as-is; this needs your server-side visibility to explain.

(Original theory kept below for reference, but should be treated as ruled out, not the actual cause):

e.onmessage = function(e){
  try { t.onData(JSON.parse(e.data)) }
  catch(t) {}
}
3

Hey @sandeep I’m checking this with the team and will get back to you as soon as I have an update.

Thank You

4

@Shah-Fazal is there any update?

5

Hey @mannan.khan There’s no update yet. I’ll let you know as soon as I hear back from the team.

Thank You

6

Hey @sandeep this is not a bug. update came over the LiveKit data channel, and v3 always runs on the gateway, so update and the talking events don’t exist there. The 37-byte message is just the gateway’s handshake, nothing is being dropped.

RetellWebClient only keeps 2.x integrations alive while v2 winds down. For transcripts use createWebCall({ transcript: true }) with onTranscript — README has the setup, including the key permission it needs: GitHub - RetellAI/retell-client-js-sdk · GitHub

Thank You