Configuration is broken for some reason. We are attempting to integrate Genesys Cloud screen recording metadata directly into ServiceNow incident records via a custom webhook. The goal is to trigger a Data Action within an Architect flow that fires immediately after a digital channel conversation ends, specifically capturing the screen recording URL and duration for compliance audit trails.
The environment is Genesys Cloud 2024-05.0 (EU-West). The ServiceNow instance is Tokyo 2307. The flow logic is straightforward: upon conversation end, a Data Action calls a custom ServiceNow REST endpoint /api/now/table/x_custom_screen_rec using POST. Authentication is handled via OAuth 2.0 client credentials, which has been validated independently and returns valid tokens.
The issue arises when the conversation includes a screen recording session. The webhook payload sent from Genesys Cloud to the ServiceNow endpoint contains the recording_uri field, but ServiceNow returns a 400 Bad Request. The error response body indicates a validation failure on the recording_uri field, claiming it exceeds the maximum length of 255 characters. This is incorrect, as the URI is a standard S3 link and well within limits.
{ "error": "VALIDATION_ERROR", "message": "Field recording_uri value is too long", "status": 400 }
We have verified the payload structure in the Genesys Cloud webhook logs. The recording_uri is correctly populated. However, when we inspect the raw HTTP request captured via a proxy, it appears that Genesys Cloud is encoding the URI in a way that ServiceNow’s REST API parser misinterprets as exceeding the limit, possibly due to double-encoding or special character handling in the path.
Has anyone encountered this specific mismatch between Genesys Cloud’s webhook payload encoding and ServiceNow’s REST API field validation? We are considering adding a script include in ServiceNow to decode the URI before validation, but we suspect the issue lies in how Genesys Cloud constructs the webhook body for screen recording metadata. Any insights on the expected format or known issues with URI encoding in recent releases would be appreciated.