Web Messaging SDK v2.7.0 - authenticated visitor data loss after pre-chat form submit

General Discussion
1

Hey all,

So, this one’s got me spinning my wheels a bit. We’re seeing authenticated visitor data - specifically, the email address - getting dropped after a user submits the pre-chat form. Feels…familiar. Had almost the exact same thing happen back in late '22, turned out to be a weird interaction between the SDK’s session handling and our data action update.

Right now, flow looks like this: visitor authenticates via a custom login widget → SDK sets visitor info (email, name) → visitor lands in chat → pre-chat form pops up. The pre-chat form itself isn’t doing anything fancy, just grabbing a few extra details. But after the submit button is pressed, the email address in the SDK’s getCurrentVisitor() is blank.

We’re using the Web Messaging SDK v2.7.0. The authentication piece is handled on our side, passing the email address to the SDK via setVisitorInfo() before the chat window even opens. It’s been rock solid for months, so I initially ruled out anything with the auth flow itself.

Digging through the network logs, the pre-chat form POST to the messaging endpoint is completing successfully. The data action we’re using is a basic REST POST, just updating a custom contact attribute. It’s not even trying to overwrite the email address - it’s just adding other fields. But something is clearing the existing visitor info.

Spent like 3 hours on this yesterday, bouncing between the SDK documentation, the REST API docs, and the Architect flow. Feels like a race condition somewhere. Maybe the data action update is triggering a re-initialization of the visitor object within the SDK? I’m grasping at straws.

Here’s what we’ve tried so far:

  • SDK version: verified we’re on 2.7.0. Rolled back to 2.6.0 just to see if it was a regression - no change.
  • Pre-chat form data action: simplified to only POST a single, non-sensitive field. Still causes the issue.
  • Data action timing: delayed the data action execution in Architect by 5 seconds. Didn’t help.
  • SDK initialization order: double-checked that setVisitorInfo() is called before the chat window is displayed.
  • Debugging console: The SDK console is mostly quiet, no errors showing up. It’s doing jack all.
  • Architect flow: verified the flow is not overwriting the visitor information.

The strange thing is, it’s intermittent. Happens maybe 60% of the time. It’s driving me nuts.

// Example SDK snippet - this is where we set the visitor info
webMessaging.getCurrentVisitor()
 .then(visitor => {
 visitor.setEmail(userEmail); // userEmail is populated from auth
 visitor.setName(userName);
 webMessaging.setVisitorInfo(visitor);
 });

Any thoughts?

1 Like
2

Fun one today. We hit a similar snag where pre-chat data just vanished during the handoff. Why does this happen? It’s usually because the session doesn’t map the authenticated identity to the contact record fast enough. The quickest fix is to stop relying on the SDK’s automatic pass-through and just force an enrichment call via a Spring Boot service as soon as the session starts.

Just hit /api/v2/externalcontacts/contacts/enrich with the email address from the pre-chat form. It’ll bridge the gap by creating or updating the contact record immediately so the flow can actually find the data.

ExternalContact contact = new ExternalContact();
contact.setEmail("user@example.com");
contact.setFirstName("John");
// Use the Java SDK to push this before the flow hits the data action
externalContactsApi.postExternalContactsContactsEnrich(contact);
3

The point made in the earlier reply is spot on (it’s a classic race condition between the identity provider and the session initialization), but it’s also worth noting that if the visitor is already authenticated, you should explicitly push that identity into the external contacts system to ensure the pre-chat form doesn’t overwrite the existing profile with null values (which is where the data loss usually happens during the transition). You’ll want to use the /api/v2/externalcontacts/contacts/enrich endpoint to lock in those attributes before the session fully hands off to the agent (this prevents the SDK from treating the submit event as a “new” visitor and wiping the authenticated context), so just make sure your payload looks something like this:

{
 "contact": {
 "email": "user@example.com",
 "firstName": "John",
 "lastName": "Doe"
 },
 "enrichmentSource": "WebMessagingSDK"
}
1 Like