Context:
Looking for advice on SIP trunk registration failures during WFM events. The system returns 403s specifically when shift swaps trigger, suggesting concurrent API throttling on the hybrid integration layer. We are deploying a BYOC Edge node in the London region (eu-west-2) to handle high-volume digital channel traffic. The primary objective is to route inbound chat transcripts via a Data Action to ServiceNow for automated incident creation. The Edge node is running the latest stable release, but the webhook endpoint defined in the Architect flow is consistently failing with a 504 Gateway Timeout after exactly 30 seconds.
The payload structure adheres to the standard ServiceNow REST API schema for incident creation, including fields for short_description, caller_id, and category. We have verified that the ServiceNow instance is reachable from the Edge node’s IP range, and manual cURL tests from the Edge container succeed with a 201 Created response. However, when triggered via the Genesys Cloud Data Action, the connection drops. The Architect flow logs indicate that the Data Action completes, but the downstream HTTP request fails. We suspect this might be related to the TLS handshake overhead or the payload size exceeding the default buffer limits on the Edge proxy.
Question:
Has anyone encountered similar latency issues with BYOC Edge nodes when integrating with external REST APIs like ServiceNow? Specifically, are there known configurations for increasing the timeout threshold on the Edge webhook handler, or should we be looking into optimizing the JSON payload structure to reduce serialization time? We have already attempted to flatten nested objects within the transcript data, but the timeout persists. Any insights into the specific HTTP headers required for the Edge node to maintain a persistent connection would be appreciated. We need to ensure that the integration remains reliable during peak hours without introducing additional latency to the agent’s screen pop experience.