Phone call_logs and call_history API compatibility

After learning about the deprecation of the call_logs API and reading the post here: Zoom Phone call log deprecation I decided to proactively replace the call_logs API references in my code with call_history. The way the notice is written, it sounds like the call_history API is a drop in replacement for the call_logs API. NOT SO! The API returns very different data. So, a couple of things:

  1. Can Zoom tweak the call_history to return the same data, please?
  2. If #1 isn’t an option, could Zoom provide code that would return the same data, more or less, so we can quickly change the API call?

I have some very stable, complex code that uses the call_logs API and a little help in transitioning would be a plus.

Thanks!

Pete

1 Like

We have noticed that the charge, rate and path fields have been removed.
There does not appear to be a replacement for these fields, except perhaps calling the user calls endpoint. This is unfeasible for many users.
Can we please get a reply for this before the endpoints become depreciated.

Hi @ciaran.grimes , can you please provide the exact endpoint links?

Gianni, I think she is referring to https://api.zoom.us/v2/phone/call_logs and https://api.zoom.us/v2/phone/call_logs/ {callLogId} The notice I referenced above says to “Please migrate to /phone/call_history and /phone/call_history/{callLogId}” But you offer no instructions and the returned JSON between the two API’s is VERY different. So you just can’t drop in /phone/call_history as a replacement for /phone/call_logs. My question, and perhaps this one from Ciaran is "How do we “migrate”? Zoom deprecated the API without a clear, documented path to “migrate”.

So, can we get some help here? I’d like to “migrate” sooner rather than later… :slight_smile:

Pete

Hello @gianni.zoom , I decided to add to this thread a question I have regarding the migration of the new API, I hope it doesn’t cause any conflict.

Like @pete_h, I have started with the migration from “/phone/call_logs” to “/phone/call_history” but I have detected that the structure has significant changes (at least with some fields that I use), could you tell me how I can recover the fields “user_id”, and “caller_user_id” that currently exist in the “call_logs” endpoint and that in the new “call_history” endpoint no longer exist. Within my flow this data is important because from here on for each call made I recover the complete information of the user with the endpoint “phone/users/{user_id}”

Thank you in advance for any help you can provide me

HI @pete_h @francisco.cercado ,

Thank you for your patience and clarifying. Your challenges are aligned with the feedback shared here: How to obtain the root call log id? - #7 by gianni.zoom

I facilitated some conversations with our Phone API team about these challenges earlier this year and was told it would be addressed in Q3, but it has not. I have followed up, sharing both of your feedback.

To summarize the issues you’ve presented are:

  • Lack of migration guidance: Zoom deprecated the /phone/call_logs API without providing clear, documented instructions on how to migrate to /phone/call_history.
  • Significant differences in returned JSON: The data structure between the two endpoints is very different, making it impossible to use /phone/call_history as a simple replacement for /phone/call_logs.
  • Missing fields: Key fields like user_id and caller_user_id from /phone/call_logs are no longer present in /phone/call_history, which is critical for retrieving detailed user information via other API calls (e.g., /phone/users/{user_id}).

The main request is for clear migration instructions and guidance on how to recover missing fields.

The internal request for this is ZSEE-126421 – we do not have a way for you to publicly track, but I can update this thread as my conversation with them progresses and escalate.

Please let me know if there’s anything I’ve not captured.

Closing out and consolidating this post to direct customers to this thread:

Feature requests based on extensive customer inputs in review.