Facing a critical integrity issue with the Bulk Export API for digital channels (specifically WhatsApp and SMS) in the London region (v2024.02). The requirement is to export message transcripts and associated media for a legal discovery request involving high-volume interactions.
The export job initiates successfully, but the resulting JSON files contain timestamp mismatches. The created_date field in the API response aligns with UTC, but the local device timestamps embedded in the WhatsApp metadata are shifting by +1 hour during peak daylight saving transitions. This discrepancy breaks the chain of custody for the legal team, who require exact synchronization between the platform logs and the user-facing timestamps.
Additionally, when filtering for messages flagged with ‘legal_hold’, the JSON payload is omitting the custody_chain metadata block entirely. The API documentation states this field should be populated for any interaction under hold status. Testing with the Postman collection provided in the developer portal yields the same result: the field is null or missing, despite the conversation object clearly showing the hold status as active.
Has anyone encountered this specific metadata omission when exporting digital channel data for legal holds? The issue persists across multiple export jobs scheduled via cron. The S3 bucket receives the files, but the integrity check fails due to the missing custody data.
Steps taken:
- Verified the legal hold status is active in the Conversation UI.
- Checked the Bulk Export job configuration to ensure ‘Include Metadata’ is checked.
- Tested with a small batch of 10 conversations to isolate the issue.
- Confirmed the S3 bucket permissions allow full read/write access.
The error log from the export job shows:
{"status": "completed", "error_count": 0, "warnings": ["Metadata fields incomplete for legal_hold items"]}
This warning appears consistently. Is there a known limitation with digital channel metadata in the current London region version? Or is there a specific parameter required in the bulk export request body to force the inclusion of custody chain data?
Any insights or workarounds would be greatly appreciated. The legal deadline is approaching, and manual reconciliation of timestamps is not feasible for the volume of data involved.