Visitor identity and verification
Understand what the current widget remembers and which identity APIs are unavailable.
Browser continuity
The widget persists a visitor token in localStorage and the active conversation ID in sessionStorage. It can retrieve prior conversations for that visitor. Another browser, cleared storage or an unrelated device may create a separate session.
Pre-chat identity
The pre-chat form can provide a name and email address. These are useful customer context, but a typed email does not prove ownership and must not authorize disclosure of private orders.
Signed login integration is unavailable
The current public widget API does not accept identify, userId or userHash. There is no Settings > Security > Identity verification signing-secret workflow for this widget. Do not implement the old HMAC examples or assume they authenticate a visitor.
Customer context and access are separate
Supported backend integrations can associate contacts and support history within a workspace. That is different from proving the browser user is that customer. Do not automatically merge people solely because they typed the same email.
Shared-device considerations
The widget has no public signout or reset method. Do not promise that logging out of your website clears the widget’s separate browser session. If your product requires authenticated chat isolation on shared devices, confirm a supported identity design before rollout.
Private order lookups
Use the secure order-verification experience provided by a supported commerce connector. Test both the intended customer and a person claiming someone else’s email before enabling customer-facing answers.