Web Messaging SDK: Custom launcher config ignored in production

We’re trying to standardize the Web Messaging widget across our portals. The goal is to pin the launcher to the bottom-right and override the default green with our brand hex #0056b3.

I’ve set up the configuration object before initializing the SDK. The code looks like this:

const config = {
 gateway: 'https://{organizationId}.eng.genesyscloud.com/webmessaging',
 launcher: {
 position: 'bottom-right',
 color: '#0056b3'
 },
 conversation: {
 greeting: 'Hi there'
 }
};

genesysCloudMessaging.init(config);

It works perfectly in the local dev environment. The launcher appears in the correct spot with the right color. However, once I push this to our staging environment, the widget reverts to the default top-left position and the green color.

I’ve checked the network tab. The init call succeeds with a 200 OK. No console errors. I even tried hardcoding the values directly in the init call without the separate config object, but it still defaults to the template settings defined in the Genesys Cloud admin UI.

Is there a priority order here? Does the admin UI configuration override the SDK initialization parameters? I read somewhere that the admin settings take precedence if the deployment is linked to a specific IVR flow, but I don’t see a flag to disable that inheritance in the SDK docs.

We’re using version 1.4.2 of the SDK. Any pointers on how to force the client-side config to win? Or is there a specific API call I need to make to update the deployment settings dynamically before init?

Currently just guessing at the override mechanism.

Launcher config needs to go inside the widget object, not top level. Also, production gateways usually differ from staging. Check your org ID.

const config = {
 gateway: 'https://{orgId}.eng.niceincontact.com/webmessaging', // Verify endpoint
 widget: {
 launcher: {
 position: 'bottom-right',
 color: '#0056b3'
 }
 }
};

Double check the docs for your specific SDK version. Structure changes often.

Spot on. The nesting is strict. You’ll also want to check the gateway URL matches your actual org ID in prod, since that often breaks silently.