SIP Trunk Bulk Export Failing with 403 on Legal Hold Metadata

So I’m seeing a very odd bug with our bulk export jobs for SIP trunk recordings. We are using the v2/recordings/bulkexport endpoint to pull data for a legal discovery request, specifically targeting interactions tagged with legal-hold=true. The issue arises when the export job attempts to write the files to our S3 bucket. While the audio files themselves upload successfully, the metadata injection step fails with a 403 Forbidden error, citing AccessDenied due to x-amz-meta-chain-of-custody headers being rejected by our bucket policy. This is strange because our S3 policy explicitly allows s3:PutObject with these specific metadata keys. We have verified the IAM role attached to the integration has the correct permissions, and manual uploads via CLI work fine. The error occurs consistently for SIP recordings but not for WebRTC, suggesting a difference in how the metadata is serialized or signed during the bulk export process for telephony channels. We are on version 12.4.0 of the platform. The Architect flow correctly tags the interaction at the start, and the analytics API confirms the tag exists. However, the bulk export job logs show a timeout followed by the metadata rejection. We need to preserve the chain of custody for compliance, so dropping these headers is not an option. Has anyone seen this specific conflict between the bulk export service and S3 bucket policies regarding custom metadata headers for SIP recordings? We have checked the audit trails and found no evidence of permission changes on the AWS side. The issue started after the last platform update, which included changes to the recording storage architecture. We are currently blocked on this discovery request. Any insights into how the bulk export service handles metadata signing for SIP vs WebRTC would be appreciated. We are considering switching to a different export method, but the v2/recordings/bulkexport endpoint is the only one that supports our required volume and metadata retention policies.

TL;DR: Check the IAM policy.

You need to grant your WFM service account explicit s3:PutObject permissions on the target bucket. The 403 indicates the export job lacks the authority to write the metadata files, even if the audio stream succeeded.