Why does this setting trigger a persistent 502 Bad Gateway when initializing the Web Chat widget in the EU-West region, specifically when migrating from a Zendesk Chat environment? We are attempting to replicate the legacy Zendesk behavior where chat sessions persist across browser refreshes, but the Genesys Cloud genesyscloud-purecloud-web-widget SDK version 2.15.0 seems to reject the sessionPersistence configuration. The error log in the browser console shows Failed to load resource: the server responded with a status of 502 () immediately after the init() call. In Zendesk, we simply toggled a setting in the admin panel, but here the deploymentId and region parameters are correct, yet the connection to the webchat.gateway endpoint fails. The Architect flow is basic, just a simple queue drop, so the issue isn’t in the routing logic. Is there a specific CORS header or DNS configuration in the Genesys Cloud admin that needs to be adjusted for the widget to handshake correctly? The userId is being passed as a unique string, matching the Zendesk externalId format, but the session token generation seems to stall. We have verified that the API user used for the widget initialization has the Chat Participant role, which should be sufficient for basic connections. This is blocking our UAT phase completely. Any insights on why the widget fails to establish the WebSocket connection despite the correct region and deploymentId? The network tab shows the initial GET request to https://webchat-eu-west-1.genesiscloud.com/api/v2/webchat/sessions returns the 502, suggesting a backend routing issue rather than a client-side SDK bug. We need to know if this is a known limitation of the current SDK or if there is a hidden configuration step in the Genesys Cloud admin portal that mimics the Zendesk persistence settings. The team is stuck waiting for this to resolve before we can proceed with the digital channel cutover.