Issue: Contact Center APIs do not provide modified_date / insert_date for incremental synchronization
Hello Zoom Developer Community,
I am facing a data consistency issue when consuming Zoom Contact Center APIs and would like to understand the recommended approach for handling late-arriving or updated records.
Currently, the endpoints I use do not expose fields such as modified_date, updated_at, created_at, or insert_date. Because of this limitation, my incremental load strategy is based on the start_time field.
My current process is:
Retrieve the latest start_time stored in my database.
Subtract 2 hours from that timestamp as a safety window.
Use the adjusted timestamp as the API from parameter.
Use the current timestamp as the API to parameter.
All requests are made without specifying a timezone, so everything is handled in UTC.
However, I have noticed that when I reprocess historical periods, records that were previously loaded are returned with updated values, causing my database records to be updated. This suggests that the data available through the Zoom API can change after the original event occurred.
The challenge is that, without a field indicating when a record was created or last modified, it is impossible to reliably identify which records have changed since the last synchronization. Using start_time alone does not capture updates made to older records.
My questions are:
Is there any recommended strategy for incremental synchronization of Contact Center data?
Are there plans to expose fields such as modified_date, updated_at, or similar metadata in Contact Center reporting endpoints?
Is there another endpoint or mechanism that allows consumers to identify records that were updated after their original start_time?
Any guidance would be greatly appreciated, as this limitation makes it difficult to guarantee data consistency in downstream analytics and data warehouse environments.
Are there specific endpoints that you are working with? Or is this concern regarding all reporting endpoints? If specific ones, please list them in your reply. In regard to exposing the named fields, I will speak to the team about this as a feature request.
This concern applies to pretty much all of the Contact Center reporting endpoints I am currently using. All of the endpoints below have the same limitation: they do not provide a reliable modified_date, updated_at, created_at, insert_date, or similar field that can be used as a reference for incremental synchronization and detecting changes to previously returned records.
In all of these cases, I currently have to rely on the event’s start_time as the reference point for incremental synchronization. However, as mentioned in my original post, records associated with older start_time values can subsequently be returned with different values when the same historical period is queried again.
So the main issue is not simply identifying new records, but also reliably detecting changes to records that were already retrieved.
I appreciate you raising this with the team as a feature request. Having a field such as modified_date or updated_at would make incremental synchronization much more reliable and would allow downstream systems and data warehouses to maintain data consistency.