I’m completely stumped as to why the CRM customer ID isn’t sticking when I call startChat(). I’m passing it in the attributes object, but the Architect data action on the other side sees undefined.
genesys.cloud.webMessaging.startChat({
attributes: {
crmId: 'CUST-12345'
}
});
No errors in console. Just null data. Is there a specific key required or is this a known bug with the current SDK version?
you’re likely hitting a scope issue or the SDK version doesn’t support deep nesting in the initial handshake. i ran into this exact thing while building my .NET dashboard backend. the web messaging client sometimes drops custom attributes if they aren’t strictly stringified or if the flow doesn’t explicitly map them.
try passing the attributes as a serialized JSON string instead of an object, or ensure your Architect flow has a “Set Participant Attributes” step right after the chat starts.
here’s how i structured the payload in my .NET service to force the attributes through:
var config = new Configuration("https://api.mypurecloud.com", clientId, clientSecret);
var client = new PureCloudPlatformClientV2(config);
// Ensure the flow expects these keys
var flow = await client.FlowApi.PostFlowsExecuteAsync(new PostFlowsExecuteRequest {
Body = new FlowExecutionRequestBody {
ParticipantAttributes = new Dictionary<string, string> {
{ "crmId", "CUST-12345" }
}
}
});
if you’re doing this purely on the client side with the JS SDK, check if you need to use genesys.cloud.webMessaging.updateAttributes after the chat is established. startChat often only passes basic routing data. i found that waiting for the onChatStarted event and then pushing the crmId via updateAttributes worked way better than trying to stuff it into the start call.
also, make sure your Architect flow actually reads from participant.attributes.crmId. sometimes the path is nested under customAttributes depending on the SDK version. i’m still figuring out the OAuth grant types for this, so i can’t help with token issues, but the attribute mapping is definitely a pain point. check the flow debug logs to see if the data arrives at all. if it’s null there, it’s a client-side drop. if it’s there but the data action fails, it’s a flow config error.