We noticed we CallLog.CallIds had changed from what seemingly was an int64 string ( if it was not a forwarded call as those would have an index attached separated by an underscore ) but now they are showing up as Hex Strings sometimes.
Was this announced, or on purpose? Mainly curious about this cause it broke some a tool of ours used to store calls internally. The examples and all callids came through before 12/11 as int64s and we used them to order our calls but now obviously since that changed it broke things.
We understand that we took the assumption as the schema does in fact document it as “string” but it was working for several months until 12/11.
So really, I was just curious about the topic, and think you should maybe update the example on the call log api endpoint to show a callid appropriately so people know that the it can potentially come in as hex string or with the appended _{index} on the callid.
Hi @ctc.aaron
Thanks for reaching out to us and for bringing this to our attention.
I am not aware of any changes made to the callID, could you point me to the Doc that you are referring so I can do some testing on my end and bring this up with the right team please?
Thanks
Elisa
Notice how “call_id” is all numerical, that was observed as accurate for several months but on 12/11/23 it changed to sometimes come in as “0658096452c310c0a87” for example. Also the variant which would come in as “7314014209231186598_1” (if it has been forwarded?
I get that it technically still falls within the schema but maybe update the example to have show all possible id types as to prevent assumptions and or allow people to account for all variants.
We wanted to use that as a way to order calls which was used in our previous system but will just go to ordering by date time I guess.
We did tests and had thousands of calls come in as int64 ( as string ) prior to 12/11/23
In my case, they haven’t changed, but I rely on the fact that transferred calls use the following form for call id: XYZ_N, where XYZ are digits and N is an index on the call path. If these were to change, it would break our product.
I’m not sure if its because we have most calls coming inbound over Auto Receptionists and something was changed for those on the backend? We have not changed our configuration since we switched to Zoom but this started randomly.
Example calls:
// Seemingly the first call to have this new format
"CallEndTime": "2023-12-11T19:28:05Z",
"CallId": "0657762432a321c7e64",
"CallEndTime": "2023-12-18T18:58:48Z",
"CallId": "0658096082a311d425e",
"CallEndTime": "2023-12-18T18:59:01Z",
"CallId": "0658096452a310a0c87",
I’m not sure why this began, but you may want to prepare for this change just in case it may happen to you… Not sure why it began, but out of no where it broke our internal application.
As I said before, our backend app relies on this feature to know when the call was transferred, sort all call parts by call_id and date_time, which is not accurate up to the microseconds, and analyze the logs (and even with this, I have to do a lot of magic to handle the transfers right).
If this feature is missing or deprecated, how can we achieve the same? The call log API and webhooks events are already inconsistent, and there is no way to link one segment of the call to the other. Can you throw some light on this, @elisa.zoom , or someone from the dev team?
Prior to 12/11, were all CallLog.CallIds consistently represented as int64 strings, with the exception of forwarded calls which included an index separated by an underscore?