# Live transcript (update event) never fires under v3 gateway transport
**URL:** https://community.retellai.com/t/live-transcript-update-event-never-fires-under-v3-gateway-transport/3648
**Category:** Support Help
**Tags:** bug
**Created:** [September 15, 2026, 6:56am UTC](https://community.retellai.com/t/live-transcript-update-event-never-fires-under-v3-gateway-transport/3648 "2026-09-15T06:56:35Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@sandeep](https://community.retellai.com/u/sandeep)
#### Post date: [September 15, 2026, 6:56am UTC](https://community.retellai.com/t/live-transcript-update-event-never-fires-under-v3-gateway-transport/3648/1 "2026-09-15T06:56:35Z")
**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`):
```auto
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.
---
### Author:  [@sandeep](https://community.retellai.com/u/sandeep)
#### Post date: [September 15, 2026, 9:03am UTC](https://community.retellai.com/t/live-transcript-update-event-never-fires-under-v3-gateway-transport/3648/2 "2026-09-15T09:03:16Z")
**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`):
```auto
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.
> [@sandeep](#):
>
> **ry:** 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)
**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):_
```auto
e.onmessage = function(e){
try { t.onData(JSON.parse(e.data)) }
catch(t) {}
}
```
---
### Author:  [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)
#### Post date: [September 15, 2026, 12:34pm UTC](https://community.retellai.com/t/live-transcript-update-event-never-fires-under-v3-gateway-transport/3648/3 "2026-09-15T12:34:41Z")
Hey @sandeep I’m checking this with the team and will get back to you as soon as I have an update.
Thank You
---
### Author:  [@mannan.khan](https://community.retellai.com/u/mannan.khan)
#### Post date: [September 16, 2026, 8:22am UTC](https://community.retellai.com/t/live-transcript-update-event-never-fires-under-v3-gateway-transport/3648/4 "2026-09-16T08:22:13Z")
@Shah-Fazal is there any update?
---
### Author:  [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)
#### Post date: [September 16, 2026, 12:47pm UTC](https://community.retellai.com/t/live-transcript-update-event-never-fires-under-v3-gateway-transport/3648/5 "2026-09-16T12:47:45Z")
Hey @mannan.khan There’s no update yet. I’ll let you know as soon as I hear back from the team.
Thank You
---
### Author:  [@Shah-Fazal](https://community.retellai.com/u/Shah-Fazal)
#### Post date: [September 17, 2026, 5:55pm UTC](https://community.retellai.com/t/live-transcript-update-event-never-fires-under-v3-gateway-transport/3648/6 "2026-09-17T17:55:27Z")
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](https://github.com/RetellAI/retell-client-js-sdk#events)
Thank You