Messaging API bulk export failing with 403 on legal hold metadata

Could use a hand troubleshooting this recurring issue with our Digital Channels bulk export jobs. We are using the Recording API v2 to fetch WhatsApp session data for legal discovery. The job initiates correctly, but fails with a 403 Forbidden error specifically when the legal_hold_metadata flag is enabled in the request payload. Standard exports without this flag complete successfully. The API key has recording:read and legalhold:read scopes assigned. Why does including legal hold metadata trigger a permission denial on WhatsApp session exports?

The configuration error likely stems from a misalignment in how the legal hold scope is applied to the specific queue or user group associated with the WhatsApp channel. Ensure the API key is attached to a user account that has explicit Legal Hold: Read permissions within the Organization > Users settings, not just the scope definition.

{
 "export_type": "digital_sessions",
 "filters": [
 {
 "attribute": "channel",
 "operator": "eq",
 "value": "whatsapp"
 }
 ],
 "include_legal_hold_metadata": true,
 "scope": {
 "user_ids": ["user_id_with_legal_hold_role"],
 "queue_ids": ["whatsapp_queue_id"]
 }
}

Review the Performance Dashboard for the WhatsApp queue to verify if there are any anomalies in conversation handle times or drop rates that might trigger a security review during bulk operations. The 403 error often correlates with elevated system load or compliance checks when metadata extraction is requested.

A common fix involves verifying that the legal hold metadata flag is compatible with the current release version of the Digital Channels API. If the issue persists, check the Audit Log for any recent changes to the security policies governing bulk data exports. The documentation suggests that legal hold metadata requires additional validation steps when combined with real-time queue activity metrics.

have you tried checking if the api key user has legal hold permissions at the org level not just scope? we saw this fail when the user lacked explicit legal hold: read in org > users.