To obtain the root call log ID on an Android device, you typically need root access, which involves bypassing security restrictions to gain privileged control over the operating system. However, it’s important to note that rooting a device can void warranties and potentially expose it to security risks. Once rooted, you can access the call log database directly through a file explorer or use specialized apps designed for rooted devices to retrieve the call log ID.
Hi all, I have escalated this for fresh visibility (ZSEE-125976). Waiting for update from the respective engineering team.
1 Like
Hi All, I had to make a feature request for the new endpoints to accept the historical alphanumeric call id (ZSEE-126421). Request is pending review.
Hi @gianni.zoom - thank you for submitting the new feature request. I believe we were hoping the new endpoints would also accept the numeric (not alphanumeric) call_id to retrieve a call log. ex: 1111222233334444555
As the description of the old endpoint stated: “callLogId” = both callLogId and callId can be used as path parameters.
Can you please verify which was submitted?
Thank you!
Hi @ddesimone , thank you for catching that! I mis-wrote in my response. The feature request (ZSEE-126421) has the correct request.
1 Like
Hi @gianni.zoom - any update on this change request? We are receiving reminders again about the Nov 2025 deprecation date of the endpoints we are using and it appears nothing has changed yet on the new endpoints?
Hi @ddesimone I actually just reached back out to the PM on this yesterday! Still waiting to hear back!
Hi @ddesimone @sam8 @summerina.samar @jose can you please provide an update on your workflow experience with new call history GA release? I believe there was an update mid-December, however, I cannot track the update in the changelog, but was asked to ask you all if you’re still experiencing.
Hi @gianni.zoom! I can confirm this is still NOT WORKING. 
What I tested today:
-
Pulled all webhook content from a recent single phone call - we subscribe to multiple events (phone.callee_call_log_completed, phone.caller_call_log_completed , phone.callee_ended, phone.caller_ended)
-
Many events can come in from Zoom for a single call, and the only common value to tie them together across each of these events is the “call_id”
-
The “call_id” value is in an alpha-numeric format that may look something like “111aaa222bbb333ccc4”. It is NOT the “id” values which has a format that looks more like a GUID (ex: “xxxxx-xxx-xxxx-xxxx-xxxxx-xx”)
-
Using the “call_id”, I attempted to use the /phone/call_history_detail endpoint to retrieve full log details, but that call returns a 404 error, “call log does not exist”. NOTE: this is the endpoint that we would like fixed to accept call_id values!
-
For good measure, I used the /phone/call_history endpoint with the appropriate date range filter that would make sure I received back the record that included the same call_id from above.
-
Now, using the “id” from the /phone/call_history result, I can pull the log details from /phone/call_history_detail. NOTE: this is helpful, but does not support our webhook workflow above.
Please let me know if you need any other details!
Okay @ddesimone thank you for replying and providing your detailed experience feedback. We have a larger team now working on this disconnect for the call log and call history endpoints and webhooks migration to address this disparity. I will continue to update here.
CC @elisa.zoom
1 Like
Sharing separate but related issue with call history:
@gianni.zoom I was just reviewing the change log reference and was reminded that the endpoints are supposed to be deprecated in June 2025.
I’m sure you can understand that we will need ample time to change all of our existing code, databases and processes to fit the new endpoints. It won’t just be a change in URL. Last I looked, the JSON results for these new endpoints are NOT the same as the old JSON data (ex: more/less/changed fields). It took quite a bit of development and testing to make something useful out of the old log results (ie: parsing the data into something that would actually match what is seen through the UI).
Once the issue reported here is fixed, I’m hopeful that Zoom will extend the expiration date of these endpoints to allow us time to migrate over successfully.
1 Like
Hi @ddesimone @sam8 @summerina.samar @jose ,
I have been finally told that the issue may be that you’re using the old webhooks with the new API endpoints which is impacting tracking the calls. Please see below for how it is being mapped:
Please subscribe to the new webhooks and try with that call_id. I have communicated to the team that this information should have been fully communicated in the documentation given many were unaware. If it works, I will make a formal request to update our docs.
Thanks Gianni - I will try to test this next week.
1 Like
@ddesimone have you had a chance to check this?
This is not a good workaround as it still requires a call out to a heavy rate limit API call, but the one way I can tell to convert the numeric call ID to the alphanumeric ID to retrieve the full detail is:
- Call out to /phone/call_history?keyword=1111222233334444555 (insert your numeric call id in the keyword param)
- The response is filtered to the one or more calls that have that numeric ID
- Iterate over the response to get each alphanumeric ID in the response
- Call out to /phone/call_history_detail/20250326-fe9c3900-5187-4254-9359-590afbc40bc9 (insert actual alphanumeric ID there)
Obviously this isn’t ideal as it requires hitting that heavy API rate limit in order to transcribe the numeric ID to the alphanumeric ID. Currently this would require us to subscribe to the “Caller/callee call history is completed” webhook to get the Zoom numeric call id, then call out to the call_history API to query that ID, then iterate and finally a third step to pull the log details
2 Likes
Hi @gianni.zoom!
i can confirm the 2 webhook events you noted above DO IN FACT include the shorter “call_id” column AND the correct longer “id” column, where the “id” column value DOES matchup to the {id} required on the new “/phone/call_history_detail/{id}” endpoint.
So that is great news! It’s unfortunate that this thread, over a year old now, came down to an issue with the documentation…
Something that puzzles me though, now looking closer at the JSON results of the new endpoint, what happened to the full path details of the call??
Using an example call_id that I have, the old endpoint returns top-level call information along with a collection of 9 objects related to each segment of the call. It was returned in the “log_details” array. In this collection, we could see the path of the call, how it comes into the main ivrMenu, over to the autoReceptionist, maybe back through the IVRMenu, and finally forwarded into the callQueue where maybe 6 phones rang and was ultimately “connected” or “answeredByOtherMember”. Reference the old endpoint API here: Zoom Phone API - Zoom Developers.
I don’t see any of those granular path details now using the new endpoint. In fact, the JSON shows no collections of data - just a flat object with top-level data points. Reference the new endpoint API here - Zoom Phone API - Zoom Developers.
How do we go about getting the call path data that we had before?
Thank you!
Good morning @gianni.zoom !
I was digging more today and it looks like the “excluded” data above is covered by the GET Call Path endpoint - Zoom Phone API - Zoom Developers.
So, I think we have everything we need now to migrate our code. Thanks for your help and continued support!
2 Likes
Since the new /phone/call_history/{callLogId} requires the root log ID, and no unified event like phone.call_log_completed provides it, the best approach is to link caller and callee logs using shared metadata—like timestamps, participants, or session IDs. Here, the /phone/call_logs/{callId} endpoint can still help retrieve that data before it’s deprecated. Until a root-level event is introduced, pairing logs this way remains the most reliable method to fetch full call details.
1 Like
Hi @paul.woltman @shoaibshabeer , I followed up again with the PM to push for updates for the new logs to reflect your asks. Fingers crossed. Will continue to follow up and urge on this.