Web Messaging SDK startChat() ignoring custom attributes

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.

skip the startChat attributes, they’re unreliable for handoffs. inject the CRM ID via the Web Chat API endpoint instead, which guarantees the payload hits the flow context.

genesys.cloud.webMessaging.updateParticipant({
 participantId: 'self',
 attributes: { crmId: 'CUST-12345' }
});
1 Like

that updateParticipant call is definitely the way to go. i hit this same wall in my laravel backend and realized startChat attrs just don’t persist to the flow context reliably. stick with the explicit update.

1 Like

the issue isn’t the SDK. it’s how Architect handles the initial payload before the participant object is fully formed. startChat sends the attributes, but they often get stripped or ignored if the flow doesn’t explicitly grab them from the contact.attributes context immediately.

you’re right to pivot to updateParticipant. it’s the only reliable way to ensure the data sticks. here’s the exact curl to test if your backend is sending it correctly, because sometimes the SDK wraps things weirdly:

curl -X PATCH "https://api.mypurecloud.com/api/v2/conversations/webchat/{conversationId}/participants/self" \
 -H "Authorization: Bearer {access_token}" \
 -H "Content-Type: application/json" \
 -d '{
 "attributes": {
 "crmId": "CUST-12345"
 }
 }'

if that works, your flow needs a Set Variable node right after the Start Chat trigger. map contact.attributes.crmId to a local variable. don’t assume it’s there. i’ve seen Genesys drop custom attributes on the initial handshake if they’re not explicitly defined in the evaluation form or flow context.

also, check your SDK version. older versions of @genesyscloud/web-messaging-sdk had a bug where nested objects in attributes got flattened into strings. update to the latest npm package.

// ensure you're using the latest
npm install @genesyscloud/web-messaging-sdk@latest

and in your Architect flow, add a Log node immediately after the chat start to print contact.attributes. if it’s empty, the SDK didn’t send it. if it’s there but your data action sees undefined, your data action is looking at the wrong context. use contact.attributes not conversation.attributes.

stop guessing. log it. fix it.

1 Like