I’ve received the email `[ACTION REQUIRED] Deprecated API usage detected: Legacy list endpoints` and when i was making the migration, three fields present in POST /v2/list-calls are no longer returned by POST /v3/list-calls. These fields are critical for our ETL pipeline and their absence is a breaking change for anyone migrating from v2.
Missing fields
transcript
transcript_object
transcript_with_tool_calls
Impact
Our inbound and outbound call log ETL jobs depend on these three fields to derive other columns.
This is expected v3 behavior, not a toggle, and you’re right that it’s a breaking change for v2->v3 ETL. I diffed both endpoints against our workspace; here’s the full picture.
What changed:POST /v3/list-calls returns a lightweight call object. The only fields it drops vs POST /v2/list-calls are exactly the three you listed:
transcript
transcript_object
transcript_with_tool_calls
Everything else — call_analysis, custom_analysis_data, call_cost, timestamps, disconnection_reason, etc. — is still in the v3 list response. They thinned the list by removing only the heavy transcript blobs (transcripts are by far the largest part of a call object, so keeping them out of a paginated list keeps page size/latency sane).
The fix:/get-call is NOT deprecated: hydrate transcripts with a per-call GET /v2/get-call/{call_id}, which still returns all three fields. So the v3 pattern is:
list (v3, paginated) → collect call_ids → GET /v2/get-call/{id} for the calls you need → derive your columns
For an ETL pipeline specifically:
Only hydrate calls you actually need (e.g. ended calls) so you’re not get-calling voicemails/failed dials.
Make hydration a separate, resumable pass from the list/discovery pass, and throttle it (~5 req/s for us) — a rate-limit or timeout then can’t blow up the whole job.
Store the transcript once fetched (it’s immutable), so each call_id is get-called only once.
We migrated v2->v3 ourselves and weren’t bitten only because our sync already fetched transcripts in a second get-call pass — the list cutover was a one-line endpoint swap. If your ETL reads transcript straight off the list rows, that second pass is the piece to add.
Re “keep them in v3”: I haven’t found a flag to include transcripts in the v3 list response — the list is intentionally lean, so get-call is the supported path.
Hello @nicolas.costa Thanks for flagging this, and yes the deprecation email is legitimate.
The missing fields in /v3/list-calls are by design rather than an oversight: transcript, transcript_object, and transcript_with_tool_calls were dropped from the list response because hydrating them per call was the dominant cost on /v2/list-calls (and the main reason for the v3 cutover). There isn’t a toggle on /v3/list-calls to include them inline.
For ETL, the supported pattern is:
Page through calls with POST /v3/list-calls to get call_ids plus the call metadata.
For each call_id you need a transcript for, call GET /v2/get-call/{call_id} — this endpoint is not part of the deprecation and still returns all three transcript fields transcript, transcript_object, transcript_with_tool_calls).
If you only need transcripts for a subset of calls (e.g. filtered by outcome, duration, agent), fetching on-demand from get-call will also be cheaper end-to-end than the old v2 behavior of hydrating every call in the page.