Welcome to the RingCentral Community

First of all, I recommend you not to post full real data on public place (I deleted them on your post). You should mask or delete those data such as an account id, extension id, phone number, name etc. If you must provide real data to help a supporter to investigate, submit a dev support ticket and provide the data via the support channel.

To your question, I already explained earlier, it is possible that a call record may not have all call data at the time it is synced, but the ISync will keep track of new data of a call record and will return the same record (identified by record id) with latest updated data in a next sync. This happens more often to a long and complicated call via a call queue and the call is transferred from one agent to another agent etc.

The recording object always present on the main call record (just for the case you sync or read the call log with the "Simple" view. The recording object also present in a call leg (for "Detailed" view). In a direct call, the call recording can be easily identified the owner and you can either pick it from the main record or from the leg record. But in a call queue call, the recording object in the main record may not tell you about the owner. So you should rely on the recording object on a call leg to identify the owner.

Also, if a call is first accepted by an agent and be recorded, then the first agent blind transferred the call to the next agent and the next agent also record the call. In this case, the recording object in the main record only refer to the first recording. And there will be 2 different recording objects in the call legs, one belongs to the first agent and another one belongs to the second agent.

BTW, what is the reason you sync every min? If your account is not such busy that may produce more than 250 calls per minute, I recommend to extend the sync period to 10 mins or more.

Hi Phong,

Is RingCentral sending snapshot of the call record or the finalized call record? Because our database is showing some call records did not have recording URL saved, however when we queried RingCentral using postman for the same call record, the recording URL was there in the response. Is it possible that when our system synced one particular record, the recording URL was not available yet (maybe due to the call was still ongoing) at the moment, and at later point when we queried the same record from Postman again, the record was finalized (call was finished)? That's why we saw the discrepancies?

The sync API might handle syncing ongoing calls in a way that it would need to update a call record later when a call is completed. I don't know how to parse and update your db. But you can always rely on the call record id as a unique and primary key in your db, then when you sync and parse the sync data, if the record exists, simply update the other data fields of that record.

If syncing the data does not need to be near real-time. If it can be synced a few hours or a day from the current time, I would recommend to use the /call-log to read call records. You can set the the dateFrom = dateTo (minus ~10 millisecond) of a previous read.

There is no difference between the two APIs right? For one call id, the result would be same for both?

https://platform.devtest.ringcentral.com/restapi/v1.0/account/accountId/extension/extensionId/call-log-sync

https://platform.devtest.ringcentral.com/restapi/v1.0/account/accountId/extension/extensionId/call-log/callRecordId

We are using first one now. We may need to switch to second one since it is more flexible and allows us to specify a time range.

There should not be any different between the record you get from syncing and the record you read from the call-log.

My latest test, ongoing call is not synced until the call is completed after about 5-10 secs.

You mean it's not possible for our system to retrieve snapshot of call (ongoing call) using either API based on your latest test? The call returned from API is finalized and completed at any moment?

Yes. Call log will not log on going calls. For active calls, you can call this API to get a list of all (entire account) active calls.

That's why I recommended you to read a few hours or a day from the current date/time to make sure there is no active calls during the dateFrom/dateTo period time you call the call-log endpoint.

But if you use the /sync, then the system will take care of active calls while you sync with the Isync token.

"But if you use the /sync, then the system will take care of active calls while you sync with the Isync token."

Can you please elaborate a little bit more on how your /sync endpoint take care of active calls?

It means that at the moment you call the ISync with a valid syncToken, if the active calls are still active (even if those calls started way before the last sync) or just got completed a second ago, the system will return them the next time you ISync again.

Hi Phong,

I appreciate your patience explaining. Can you please confirm below highlighted based on what we discussed?

call-log-sync won't send active/ongoing calls to our system. I tested on my end and our endpoint didn't receive any data when the call was active. However, a call record maybe updated (multiple times) later. If an update happened, call-log-sync will send same record to us again. I noticed on my end that there were multiple syncs for one id "L1oEc04R5LgADUA" at different timestamps, which probably tells that it was updated a few times since after initial sync.

Also do you have an API that can update existing call record? I didn't find one from your API reference page.

Thank you!

As long as the SyncToken is valid, you can rely on the ISync call using the syncToken to fetch new call records, even if a call record was not completed during the previous sync.

I cannot explain in details how and when a call record might be updated multiple times. But a call record id must be the same. So when syncing the call data with your db, you just need to check the record id, if exists in your db, update it with new data, if not add a new record in your db.