I have just two more things to note that maybe you can pass along as well?
I can understand why the “new” /phone/call_history endpoint is Rate Limit Labeled HEAVY, due to the nature of potentially searching for a lot of data.
I don’t understand though why /phone/call_history/{callLogId} and /phone/call_history_detail/{callLogId} – note the use of the {callLogId} to fetch a single record – are labeled HEAVY and MEDIUM.
The previous (deprecated) /phone/call_logs/{callLogId} endpoint was LIGHT.
So now we have to build in more catch-retry or thread pause logic because we are experiencing the “Too Many Requests” error.
Lastly, these call log endpoint changes by Zoom have doubled the amount of API calls we make to get the data we need.
As an example, we have a process that fetches all prior day call history – which during a weekday could be 25k-30k+ calls.
Using /phone/call_history in batches of 300 is 80-100+ API calls. Not a big deal, but the JSON response schema for this endpoint gives a lot of detail but NOT ALL of the detail for the call.
So, now for each of the 30K+ calls we need to make 2 additional calls (instead of 1 before):
/phone/call_history_detail/{callLogId} – this endpoint returns a few more pieces of information that the first didn’t – such as “hold_time” and “wait_time” (mislabeled in the documentation as “waiting_time”)
/phone/call_history/{callLogId} – this endpoint returns us the call path data (ie: segments) that neither of the other endpoints contain. It used to be included in the deprecated “get call log details”.
Adding this up – 60,000+ API calls – happening every weekday.
Seems like incoming API traffic could be minimized by combining the 2 endpoints above. Move the call path data back into the call_history_detail endpoint and move the endpoint back to the LIGHT rate limit.
I was the one who submitted this post: Phone call_logs and call_history API compatibility - #5 by francisco.cercado One of the things I mentioned was a lack of documentation on how to migrate and, more importantly, account for the missing/changed data in the JSON returned. Was any thought given to creating a “migration guide” for this? e.g. show what the deprecated API returned and show how that data can be retrieved either mapping to new fields with the same info or additional API calls to “fill in the blanks”? This change is a fairly heavy lift and some migration “how to’s” would be very helpful…
There was some guidance shared here: Understand Zoom Phone call history , but there is a robust migration guide in the works based on all of your feedback. Many of us agree there needed to be a better resource that fully unpacks the changes and we are working to provide this. I believe part of the problem were the breaking changes customers have highlighted. This has taken time to fully communicate and rectify. Appreciate you pushing for better documentation and developer experience here!
At this point, Zoom didn’t think this through. You cannot replace something that is working (even if it is from the customer’s perspective) with something worse. The situation with the old endpoints/webhooks and the new ones is as follows: the new one is significantly worse, lacks documentation on migration, and requires substantially more work to achieve the same results. On top of this, Zoom sets a deprecation date for the old endpoints without even having a clear and stable replacement for the same functionality. This is a horrible customer experience.
Until we have a clear replacement, I cannot migrate something that is working to something unstable or untested. Zoom should extend the deprecation date until further notice until these issues are ironed out.
Hi @jose
Thank you so much for your feedback.
We are actively working on improving these endpoints, the docs and migration documentation.
I will provide you an update on the deprecation date, since it might get pushed.
Thanks a lot