Why does this setting in the Genesys Cloud Screen Recording configuration trigger a 404 Not Found error when attempting to write recording metadata to a custom ServiceNow table via a POST request? The integration was functioning correctly until the recent platform update to v2024.11, after which the Data Action execution logs show immediate failure upon invoking the webhook.
The Architect flow is configured to trigger a Data Action immediately after the conversation.status.change event where the new status is completed. The payload includes the recording_id, agent_id, and interaction_type. However, the ServiceNow side logs indicate that the request never reaches the intended table_api endpoint, instead hitting a generic routing error.
Environment details:
- Genesys Cloud Version: 2024.11.0
- ServiceNow Version: Washington DC Patch 1
- Data Action Type: Webhook (POST)
- Endpoint:
/api/now/table/u_gc_recording_metadata - Authentication: OAuth 2.0 Client Credentials Flow
- VPC Configuration: PrivateLink enabled with DNS resolution verified via nslookup
The request headers include the necessary Authorization: Bearer <token> and Content-Type: application/json. Local testing using Postman with the same token and payload structure succeeds without issue, creating the record in ServiceNow as expected. This suggests the issue lies within how Genesys Cloud constructs or routes the outbound request from the VPC environment.
Checking the Genesys Cloud Data Action logs reveals the following error snippet:
Status: 404
Message: Resource not found
Trace: /api/v2/dataactions/execute/webhook
Has anyone encountered similar routing failures when migrating to the latest Genesys Cloud release? Specifically, are there known changes to the outbound proxy configuration or DNS resolution within the VPC that might affect custom webhook endpoints? The network team has confirmed that outbound traffic to the ServiceNow instance is allowed on port 443, and no firewall rules have changed recently. Any insights into debugging the internal routing logic of the Data Action executor would be appreciated.