# CallIds changed?

**URL:** <https://devforum.zoom.us/t/callids-changed/100260>\
**Category:** Phone\
**Tags:** phone, api\
**Created:** [December 15, 2023, 9:26pm UTC](https://devforum.zoom.us/t/callids-changed/100260 "2023-12-15T21:26:53Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![ctc.aaron](https://avatars.discourse-cdn.com/v4/letter/c/ecc23a/32.png) [@ctc.aaron](https://devforum.zoom.us/u/ctc.aaron)\
**Post date:** [December 15, 2023, 9:26pm UTC](https://devforum.zoom.us/t/callids-changed/100260/1 "2023-12-15T21:26:53Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![elisa.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/elisa.zoom/32/47836_2.png) [@elisa.zoom](https://devforum.zoom.us/u/elisa.zoom)\
**Post date:** [December 18, 2023, 6:55pm UTC](https://devforum.zoom.us/t/callids-changed/100260/2 "2023-12-18T18:55:09Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ctc.aaron](https://avatars.discourse-cdn.com/v4/letter/c/ecc23a/32.png) [@ctc.aaron](https://devforum.zoom.us/u/ctc.aaron)\
**Post date:** [December 18, 2023, 7:24pm UTC](https://devforum.zoom.us/t/callids-changed/100260/3 "2023-12-18T19:24:41Z")

</div>

> **[Zoom Phone API](https://developers.zoom.us/docs/api/rest/reference/phone/methods/#operation/accountCallLogs)**
>
> API Reference for /docs/api/rest/reference/phone/methods

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

---

<div class="post-metadata">

**Author:** ![jose](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/jose/32/52765_2.png) [@jose](https://devforum.zoom.us/u/jose)\
**Post date:** [December 28, 2023, 6:53pm UTC](https://devforum.zoom.us/t/callids-changed/100260/4 "2023-12-28T18:53:06Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ctc.aaron](https://avatars.discourse-cdn.com/v4/letter/c/ecc23a/32.png) [@ctc.aaron](https://devforum.zoom.us/u/ctc.aaron)\
**Post date:** [December 28, 2023, 8:00pm UTC](https://devforum.zoom.us/t/callids-changed/100260/5 "2023-12-28T20:00:01Z")

</div>

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:

```auto
// 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",

```

---

<div class="post-metadata">

**Author:** ![ctc.aaron](https://avatars.discourse-cdn.com/v4/letter/c/ecc23a/32.png) [@ctc.aaron](https://devforum.zoom.us/u/ctc.aaron)\
**Post date:** [December 28, 2023, 8:03pm UTC](https://devforum.zoom.us/t/callids-changed/100260/6 "2023-12-28T20:03:01Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jose](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/jose/32/52765_2.png) [@jose](https://devforum.zoom.us/u/jose)\
**Post date:** [December 28, 2023, 8:26pm UTC](https://devforum.zoom.us/t/callids-changed/100260/7 "2023-12-28T20:26:21Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![sam8](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/sam8/32/63400_2.png) [@sam8](https://devforum.zoom.us/u/sam8)\
**Post date:** [January 19, 2024, 4:05pm UTC](https://devforum.zoom.us/t/callids-changed/100260/8 "2024-01-19T16:05:28Z")

</div>

I’m glad I’m not the only one. It’s ridiculous.

---

<div class="post-metadata">

**Author:** ![directballoons893](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/directballoons893/32/57127_2.png) [@directballoons893](https://devforum.zoom.us/u/directballoons893)\
**Post date:** [March 6, 2024, 7:52am UTC](https://devforum.zoom.us/t/callids-changed/100260/9 "2024-03-06T07:52:26Z")

</div>

> [@ctc.aaron](#):
>
> 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.

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?

---

<div class="post-metadata">

**Author:** ![gianni.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/gianni.zoom/32/32523_2.png) [@gianni.zoom](https://devforum.zoom.us/u/gianni.zoom)\
**Post date:** [March 6, 2024, 6:44pm UTC](https://devforum.zoom.us/t/callids-changed/100260/11 "2024-03-06T18:44:32Z")

</div>

@sam8 @ctc.aaron , are you willing to provide API examples in support of further investigation for our API and documentation teams?

---

<div class="post-metadata">

**Author:** ![ctc.aaron](https://avatars.discourse-cdn.com/v4/letter/c/ecc23a/32.png) [@ctc.aaron](https://devforum.zoom.us/u/ctc.aaron)\
**Post date:** [August 6, 2024, 2:53am UTC](https://devforum.zoom.us/t/callids-changed/100260/12 "2024-08-06T02:53:26Z")

</div>

Sorry for such a late response but this forum is pretty much a dead end for any help so I stopped coming here often. I’ll see if I can get some examples again soon. I passed the project off to one of our developers prior to this issue occurring so I’ve been hands off for a long time.

---

<div class="post-metadata">

**Author:** ![gianni.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/gianni.zoom/32/32523_2.png) [@gianni.zoom](https://devforum.zoom.us/u/gianni.zoom)\
**Post date:** [August 6, 2024, 3:24pm UTC](https://devforum.zoom.us/t/callids-changed/100260/13 "2024-08-06T15:24:20Z")

</div>

Hi @ctc.aaron sorry to hear this has been your experience. I will start a private message for you to share the screenshots as they become available, and your feedback on what you’d like to see for your developer experience on here.
