Stuck on a persistent 503 Service Unavailable error when attempting to initiate webchat sessions via the POST /api/v2/interactions/conversations endpoint in our APAC production environment. The setup involves 15 BYOC trunks distributed across Singapore and Tokyo edges, all configured with strict carrier failover logic using the Genesys Cloud v2 SDK for Python (version 156.0.0). While voice routing remains stable with sub-50ms latency on SIP registration, the digital channel integration fails specifically when the outbound routing rules attempt to map the incoming webchat participant to a BYOC trunk identifier for analytics attribution. The error payload returns {"code": "service_unavailable", "message": "Upstream service timeout"}, but checking the carrier health dashboard shows all trunks green. I’ve verified the external_contact_id format matches the required UUID structure and confirmed that the routing_skills array contains valid IDs mapped to the correct queue. The issue appears isolated to the initial session handshake; subsequent message exchanges within an established session work fine, which suggests the problem lies in the initial capacity check or trunk validation logic rather than the messaging bridge itself. We are using the Singapore edge for digital traffic, and while voice traffic routes correctly through the primary BYOC provider, the webchat connector seems to be hitting a timeout when trying to validate the trunk’s availability for the assigned agent skill group. Has anyone encountered similar latency spikes during the webchat initiation phase when using BYOC trunks for digital channel attribution? The logs indicate the request hangs for exactly 30 seconds before dropping the connection, which aligns with the default timeout for upstream service calls in the current SDK version. I need to determine if this is a configuration mismatch in the outbound routing rules or a known limitation with how BYOC trunks handle digital channel capacity checks.