Does anyone understand why the metadata json file generated by the bulk export job for digital channels does not match the actual recording file timestamp in our s3 bucket? we are using the /api/v2/bulkexport/jobs endpoint to trigger exports for legal discovery requests. the job completes successfully with status “completed” but when we download the files from the s3 destination, the metadata file contains a creation_time that is 5 minutes earlier than the actual media file modification time. this is causing issues with our chain of custody verification process.
we are in the europe/london timezone and the api response shows utc timestamps. we have verified that the s3 bucket is also configured to store objects in utc. the discrepancy seems to happen only for messenger and webchat recordings, not for voice calls. voice call metadata matches perfectly.
here is the relevant part of the api request payload we are using:
{
“mediaTypes”: [“DIGITAL”],
“exportType”: “RECORDINGS_AND_METADATA”,
“destination”: “s3”,
“filters”: {
“startTime”: “2023-10-01T00:00:00.000Z”,
“endTime”: “2023-10-01T23:59:59.999Z”
}
}
the metadata file format is standard json but the timestamps are inconsistent. we have checked the architect flow for the digital channel and there are no delays configured. the issue persists across multiple export jobs. is this a known latency issue with the digital channel recording service? or is there a specific setting in the bulk export configuration that we are missing? we need strict temporal alignment for legal compliance. any insights would be appreciated. we are using python requests library v2.31.0 to manage the export jobs and monitor status. the error is not an api error but a data integrity issue.