Zoom Phone Warm Transfer Logs Someone Got Worse

Phone
1

We are using the Zoom Phone API to retrieve call history log data for our reports, but so far we’ve spent all our time trying to convert the Zoom data into something that makes sense. Depending on the type of call, some are logged as a single call with multiple parts, while others get logged separately. Warm transfers specifically are a major problem.

If you go on the Zoom admin interface in the Admin → Phone System Management → Logs section and use the “New View” and then click the Event filter dropdown and click the arrow next to Transfer to get the option to check “Warm Transfer”, the most recent events that show are from November 15th. It seems after that point, Zoom changed the way that warm transfers are logged, but never bothered updating the website interface.

We performed a warm transfer on February 18th at 5:20pm Central time to see how it is now logging. The logs show a single inbound log, event “incoming”, call result “answered”, duration 1:03. If you click call path, it shows the initial call, and then has a blue “Continue to trace warm transfer” button. If you click that button, it expands and pulls the call data for the warm transfer, showing that the initial recipient made a call to the transfer recipient.

A web inspector shows that part of the JSON passed to the browser includes:
“actions”: [{
“time”: 1739920863245,
“type”: 10,
“extra_info”: null
}, {
“time”: 1739920869435,
“type”: 11,
“extra_info”: null
}, {
“time”: 1739920877615,
“type”: 10,
“extra_info”: null
}, {
“time”: 1739920898308,
“type”: 61,
“extra_info”: “7472903303009166744”
}],
It appears action type 10 is “Hold”, 11 is “Unhold”, and 61 is “warm transfer”, and extra_info is the call id for that second part of the call.

A call to the API at https://api.zoom.us/v2/phone/call_history does not return any of that information, so from the API it looks like a simple call from an outside phone number to the initial call recipient, and as of November 15th calls contain zero trace in the API logs that a warm transfer even happened, let alone contain any info on how to follow to the next part of the call.

Is anyone actually working on the API? It seems like it is consistently behind the web interface, the REST API doesn’t even match the webhook API (for example, the call ID sent on a webhook cannot be used to lookup call history details at the REST API).

3

Waiting to hear back on another issue that could be possibly connected to your experience. Thanks for your patience.

4

Is there any update on this yet?

5

Hi @paul.woltman ,

I’ve recently heard back on a related issue with call history endpoint not having parity with upcoming deprecated call log endpoints and web portal data.

My colleague has made me aware of an initiative with the Phone API team to reconcile these issues.

Please know I hear and sympathize with your grievances and am working to push for consistent parity experiences across our products with developer resources.

In the interim, I have formally logged your issue with Developer Support for another point of tracking. Please check the email associated with your developer forum account to see the ticket.

Here’s what I’ve communicated on your behalf:

A customer using the Zoom Phone API to retrieve call history data reports inconsistencies in how calls—especially warm transfers—are logged. They note a major discrepancy between the web admin interface and the API, making it difficult to track warm transfers in their reports.

Customer Findings:

  • Prior to November 15, warm transfers were identifiable in API logs. After this date, they are no longer visible.
  • The Zoom admin UI still presents warm transfer details, but the API does not.
  • Web inspector analysis reveals that warm transfer events (action type 61) are present in the JSON data passed to the UI but are missing from the API response.
  • API logs show only the initial incoming call, with no way to follow the transfer path.

Replication Details:

  • A warm transfer was performed on February 18 at 5:20 PM CST.
  • The web UI displayed the warm transfer event and call continuation, but a call to the /v2/phone/call_history API did not contain any related data.

Potential Root Causes:

  1. Data Discrepancy: API responses do not align with the Zoom web UI, suggesting missing or improperly surfaced data in the API layer.
  2. Schema Changes Post-November 15: The API may have undergone an uncommunicated change affecting how warm transfers are logged.
  3. Incomplete API Implementation: The REST API does not provide the same level of detail as the webhook API, leading to usability issues.

Next Steps for Escalation:

  • Engineering Review: Investigate whether warm transfer events were intentionally removed from API responses post-November 15.
  • API Consistency Check: Ensure REST API and webhook API provide aligned call history details.
  • Documentation Update (if applicable): Clarify how warm transfers are expected to be logged and retrieved via API.
  • Customer Follow-Up: Provide a timeline for resolution or a workaround if available.
6

Hi @paul.woltman , have you seen this?

7

Yes, I saw that. It doesn’t really apply, as the updated webhook still doesn’t contain the property alphanumeric ID that can be used in the /phone/call_history/ REST API call

1 Like
8

Thanks again, we’re relaying the feedback @paul.woltman and continuing to to follow up internally.

9

@gianni.zoom Can you confirm that something changed with the call history log API yesterday (May 19th)?

Starting yesterday, we are now seeing instances of “event”: “warm_transfer” in our call path details. We hadn’t see warm_transfer events show in the api since November 15th.

Unfortunately, it’s still not all that useful - now, if there is a call that gets warm transfered, we see:

  1. Incoming call that is answered by one of our users
  2. An outbound call with an event in the call_path data for “warm_transfer”, which gives the information for the user initiating the warm transfer and the user receiving the warm transfer, but doesn’t actually give any info about the original call, so there’s nothing to directly connect it to the original incoming call
  3. An incoming call with event “incoming” for the recipient of the warm transfer, with info about the user initiating the warm transfer and the recipient of the warm transfer, but again no details on what call is being received

Also confirmed that in the webhook, we now see phone.caller_call_history_completed events with a call_log child object that has a warm_transfer event. Again, no details as to the call that is being warm transferred, just an indication that a user performed a warm transfer and we have to manually hunt down the original call.

The Phone System Management → Logs page on the Zoom admin interface has also been updated - prior to November 15th, you could filter to warm transfer calls using the Event filter → Transfer → Warm Transfer. After November 15th, no calls show when you use that filter, but now there is a filter under Event filter → Ringing → Warm Transfer that shows warm transfers that happened starting May 19, 2025.

The web interface gives you the option to “Continue to trace warm transfer” that is able to link the original call with the warm transfer calls. This data still doesn’t exist in the API or webhook data.

10

@paul.woltman , just sent you a private message asking for a few details.