Stuck on injecting a customerId into the Genesys Cloud Web Messaging SDK. I’m calling startChat with customAttributes: { crmId: '123' }, but the value vanishes in the /api/v2/analytics/conversations payload. My Vue 3 composable sets the attribute before init. Is startChat ignoring customAttributes? Need the exact JSON structure to ensure the CRM ID sticks for downstream routing.
It depends, but generally… the Web Messaging SDK does not merge customAttributes passed directly into the startChat invocation into the persistent conversation context. The SDK expects attributes to be set on the client instance before the session initializes, or via the setCustomAttributes method immediately after connection establishment. Passing them in the initial config often results in the payload being ignored during the handshake phase.
From a distributed tracing perspective, I often see similar context loss when headers are injected at the wrong layer. For CRM identifiers, you must ensure the attribute key matches your Analytics schema definition. If you are using the genesys-cloud-web-messaging package, the correct pattern is to configure the client with a factory function or set attributes post-initialization.
import { createWebMessagingClient } from '@genesyscloud/web-messaging';
const client = createWebMessagingClient({
deploymentId: 'your-deployment-id',
// ... other config
});
// Set attributes AFTER the client is instantiated but BEFORE startChat
client.setCustomAttributes({
crmId: '123',
source: 'web-vue'
});
// Now start the chat
client.startChat({
customAttributes: {} // Keep this empty or for transient session data only
});
Verify that crmId is defined in your Genesys Cloud Analytics settings under Conversation Attributes. If the attribute is not whitelisted, it will not appear in the /api/v2/analytics/conversations export. Also, check the Network tab for the POST /api/v2/conversations/webchat request; the payload should contain the customAttributes object. If it is missing there, the SDK call is incorrect. If it is present but missing in Analytics, the schema is the culprit. I track these mismatches using OpenTelemetry spans on the frontend to correlate the SDK call with the backend ingestion event.