Trying to understand how to properly inject our CRM customer ID into the Genesys Cloud Web Messaging SDK before the session actually boots up. Our downstream Glue jobs expect that identifier in the conversation metadata so the Redshift COPY command doesn’t fail on null keys. The docs mention custom attributes, but the startChat() payload seems to drop anything outside the standard config object.
Current Implementation
gcMessaging.startChat({
flowName: 'Support-Flow',
attributes: {
crmId: 'CUST-99284',
source: 'webportal'
}
});
What’s Happening
The chat window opens fine, no console errors. When i pull the analytics data export later, that crmId field is completely missing from the JSON payload. The SDK just strips it out during initialization. i’ve tried nesting it under customData and context but nothing sticks. The webhook payload also shows empty strings for custom fields. Honestly feels like the guest API is filtering it server-side before it even hits the routing queue.
How do i correctly pass a CRM customer ID through the startChat method so it actually persists in the conversation record?
startChat({
attributes: {
custom: {
crmId: “YOUR_ID_HERE”
}
}
});
Ah, this is a known issue... The SDK requires the `attributes` object to be nested correctly within the config. Ensure `crmId` sits under `custom`. Glue jobs will then see it in the metadata payload.
TL;DR: The structure is correct, but timing and SDK version matter.
You might want to look at how the SDK handles the initial handshake. The nested structure shown above is definitely the way to go. startChat needs that attributes.custom block to pass metadata before the WebSocket connection fully establishes. If you’re seeing it drop, check your SDK version. Older builds had a bug where custom attributes were stripped if they weren’t stringified properly. Also, make sure you aren’t overwriting the config object elsewhere in your initialization flow. Sometimes a later updateAttributes call can clobber the initial payload if the session ID isn’t ready yet. Here is a clean snippet that works reliably in our Node.js integration tests:
const { PlatformClient } = require('@genesyscloud/genesyscloud');
// Initialize SDK
const sdk = new PlatformClient();
// Configuration with CRM ID
const chatConfig = {
organizationId: 'YOUR_ORG_ID',
deploymentId: 'YOUR_DEPLOYMENT_ID',
attributes: {
custom: {
crmId: "CRM-12345", // Must be a string
source: "web_portal"
}
}
};
// Start chat
sdk.webMessaging.startChat(chatConfig)
.then((response) => {
console.log("Chat started, attributes sent:", chatConfig.attributes);
})
.catch((err) => {
console.error("Failed to start chat:", err);
});
The key is keeping crmId as a string. If you pass an integer, some downstream parsers might reject it. Also, verify that your Glue job is actually reading from the custom namespace. Sometimes people look at system attributes by mistake. The metadata payload includes both, so double-check the field path in your Redshift mapping. If it’s still dropping, try logging the raw request payload from the browser network tab. You’ll see exactly what gets sent. If the custom object is empty there, the issue is in your JS code, not the platform.
it depends, but generally… the nesting is right. if attrs drop, check sdk version. old builds strip custom keys. try v1.2.4+. also, verify dialog engine mapping. sometimes bot flow json needs explicit slot for crmId. see docs here: https://developer.genesys.cloud/api-docs/conversations/messaging.
The documentation actually says you can pass those attributes, but it glosses over the fact that standard web messaging sessions often strip custom metadata before it hits the server-side conversation object.
// Don't just rely on startChat().
// You need to ensure the SDK version supports 'custom' attributes in the initial handshake.
// Also, verify the attribute isn't being blocked by your organization's privacy settings.
const config = {
orgId: 'your-org-id',
deploymentId: 'your-deployment-id',
attributes: {
custom: {
crmId: '12345' // This might get stripped if not whitelisted
}
}
};
// Check your API logs. If it's missing, use the REST API to patch it immediately after creation.
// Or better yet, use the 'identity' object if you're handling auth.
I’ve seen this fail silently in staging where the SDK version was slightly behind what the docs reference. The custom block gets accepted by the client but dropped by the server if the schema doesn’t match exactly. You’ll want to check the actual WebSocket payload using browser dev tools. If the crmId is there locally but missing in the Genesys Cloud conversation history, it’s a server-side filter. Consider using the identity field instead if you have an authenticated flow. It’s more reliable for downstream data pipelines.