ServiceNow Table API 400 on Genesys Cloud Screen Recording Metadata Injection

Why does this config cause a 400 Bad Request when attempting to map the screen_recording:completed webhook payload to a custom ServiceNow table via the Genesys Cloud Data Actions connector?

We are refining our digital channel integration strategy. The goal is to automatically ingest screen recording metadata into a custom ServiceNow table (u_gc_screen_recordings) for compliance auditing. The webhook trigger fires correctly in Genesys Cloud Architect. We have verified the event payload structure against the latest API documentation. The JSON contains the recording_id, agent_id, and url fields as expected.

However, when Data Actions attempts to POST this data to the ServiceNow MID Server endpoint, the integration fails consistently. The ServiceNow logs indicate that the payload schema does not match the target table definition, specifically regarding the recording_metadata object. We have tried flattening the JSON structure using the Data Actions transformation feature, but the error persists.

{"error":{"message":"Invalid JSON payload: The property 'recording_metadata' is not defined in the target schema.","status":400,"code":"INVALID_PAYLOAD"}}

The ServiceNow table schema expects a flat structure. We are mapping recording_metadata.agent_id to u_agent_id. Despite this explicit mapping, the MID Server rejects the request. The integration worked perfectly for standard conversation summary events. This issue is specific to the screen recording event type. The timestamp in the webhook payload is in ISO 8601 format, which ServiceNow accepts. We have checked the ServiceNow REST API documentation and confirmed the endpoint is active and accepting requests from other sources.

Is there a known limitation with complex nested objects in the Genesys Cloud Data Actions connector when targeting ServiceNow tables? We need to ensure the metadata is correctly flattened before transmission. Any insights on the correct transformation syntax or alternative mapping strategies would be appreciated. We are operating in the EU1 region. The ServiceNow instance is on the Washington release.