Looking for advice on a persistent integration failure between the Genesys Cloud WebRTC Softphone SDK (v1.24.1) and our ServiceNow (Tokyo Release) automated ticketing workflow. The environment is Genesys Cloud UK East, configured with a custom Architect flow to handle digital channel escalations. When a high-priority messaging interaction triggers a screen pop in ServiceNow via a Data Action webhook, the system attempts to force an agent login state change through the softphone client to ensure availability for the subsequent voice callback. The SDK throws a 503 Service Unavailable error during the login method execution, specifically when the presence payload includes a custom availability_code mapped from the ServiceNow ticket priority field. The error response from the Genesys Cloud API indicates that the agent resource is in an inconsistent state, preventing the transition from Available to On Call while the softphone is initializing. We have verified that the authorization token passed in the headers is valid and not expired, as confirmed by logging the token expiry time against the current UTC timestamp in the ServiceNow script include. The issue seems to correlate with the timing of the Data Action completion and the subsequent HTTP Request to the Genesys Cloud v2/users/me/presence endpoint. If we introduce a 5-second delay in the ServiceNow business rule before triggering the SDK login, the error rate drops significantly, suggesting a race condition between the presence update and the softphone registration handshake. Has anyone encountered similar latency issues when chaining ServiceNow REST API calls with Genesys Cloud presence management via the WebRTC SDK? We are attempting to eliminate this delay to improve the customer experience, but the current workaround is impacting our SLA metrics. Detailed logs from the Architect flow show the trigger event firing correctly, but the response from the softphone client logs indicates a WebSocket disconnect before the login sequence completes.