Injecting CRM ID into Web Messaging SDK startChat payload

Is it possible to pass a custom CRM customer ID directly through the startChat() method of the Genesys Cloud Web Messaging SDK to ensure it is available in the initial WebSocket connection handshake?

• Current implementation uses the standard JS SDK v1.2.4.
• Attempting to inject externalCustomerId via the data object in the configuration.
• Code snippet:

const config = {
brandId: 'my-brand-id',
deploymentId: 'my-deployment-id',
data: {
externalCustomerId: 'CRM-998877',
source: 'web-portal'
}
};

messenger.startChat(config);

• Observation:
• The chat initializes successfully.
• WebSocket connection established on /api/v2/messaging/connections.
• However, the externalCustomerId does not appear in the initial conversation/participants payload received via the Notification API.
• It only appears after the first message is exchanged, likely via a subsequent PATCH or attribute update.
• Requirement:
• Need the CRM ID present in the initial participant object to trigger specific routing logic via Architect Data Actions immediately upon connection.
• Routing logic relies on event.data.participants[0].attributes.externalCustomerId.
• Delay in attribute availability causes routing misfires for high-priority CRM segments.
• Questions:
• Is there a specific parameter name required in the data object for immediate attribute propagation?
• Should I be using the customAttributes field instead of generic data?
• Is this a limitation of the SDK or the backend WebSocket bridge?
• Any known workaround to force immediate attribute sync on startChat?
• Environment:
• Genesys Cloud US01.
• SDK loaded via CDN.
• No custom build of the SDK.

This is actually a known issue. The SDK ignores externalCustomerId in startChat config. You must set it via setParticipantAttribute before initiating the session.

Error: Participant attribute ‘externalCustomerId’ is missing in inbound flow data action.

Use this pattern to ensure persistence.

You should probably look at at the backend. The suggestion above works for the SDK, but Architect needs the ID in the inbound flow data.

# Use the platform API to push attributes if SDK fails
platformClient.conversations_api.post_conversations_messaging_participant_attributes(conversation_id, body=attrs)

The simplest way to resolve this is to inject the attribute via the API since the SDK often drops it during the handshake. The documentation states: “Participant attributes must be set after the conversation is established.”

1. Capture the conversationId from the onConversationCreated event.
2. Call POST /api/v2/conversations/messaging/{conversationId}/participants/{participantId}/attributes with {"externalCustomerId": "123"}.

// Wait for session init, then push attributes
session.on('session:connected', () => {
 session.setParticipantAttribute('externalCustomerId', '123');
});

The suggestion above is correct. The SDK handshake doesn’t carry custom data. You must set participant attributes after the WebSocket connects. This ensures the ID is available for subsequent API calls or flow routing logic.