Page-known visitor identification | Stand Feature Reference

01

What visitor identification does

By default, a new website conversation begins with an anonymous participant named Visitor. If the host website already knows who is signed in, it can give Stand a stable external ID and, optionally, a display name before the conversation starts.

Stand stores that identity with the new session. The optional name helps authenticated reps recognize the visitor during the live conversation and find the conversation later in History. The external ID remains private and is not returned in the visitor chat, dashboard session response, History results, or conversation exports.

This is useful when a customer is already signed in to an account, portal, or application and should not have to introduce themselves again. It is not an authentication mechanism: Stand accepts the identity as page-supplied context and does not verify that it belongs to the person using the browser.

02

Enable it from your website

There is no dashboard switch for visitor identification. Install Stand normally, then call window.StandChat.identify(...) from the host website after the Stand script has executed and before the visitor starts a new conversation.

Use an identifier from your own account system. It should be stable for the same customer but should not be a password, session token, access token, or other secret. The name is optional.

Identify the signed-in customer

const customer = getSignedInCustomer()

window.StandChat.identify({
  externalId: String(customer.id),
  name: customer.displayName,
})

Run this after the Stand embed script is ready and before the first visitor message creates a session.

When the website signs the customer out or switches accounts, call window.StandChat.identify(null). This clears the page-level identity for conversations created afterward.

03

Choose how long the identity applies

Stand supports a page-level identity for ordinary signed-in experiences and a one-conversation identity for custom entry points. In every case, the identity is read when Stand creates the session; it does not rewrite an active or restored conversation.

Method	Scope	Use it when
`StandChat.identify({ externalId, name })`	Every new session created during the current widget runtime, until the identity is replaced or cleared.	The same signed-in customer can open Stand from several places on the page or application. Call it again when a new page load initializes Stand.
`StandChat.openChat("", { visitorIdentity })`	Only the next session created by that open request. It does not carry into a later conversation.	A custom button or flow supplies identity for one specific conversation.
`visitor-id` and `visitor-name` on `stand-card`	Only the session created when that card’s Stand action is activated.	A declarative Stand card is tied to a known account or record without additional click-handler JavaScript.

04

What each person can see

Surface	Visible behavior
Visitor chat	Neither the external ID nor the optional page-supplied name appears as a message or identity field. The feature does not tell the visitor that they have been authenticated.
Live rep view	An authenticated rep sees the optional name in place of the generic Visitor label. The external ID is not exposed.
History and search	The optional name remains available with the closed conversation and can match History text search. The external ID is not included in History results.
Conversation export	The effective visitor name can appear in the exported conversation. The external ID and the private identity field names are excluded.

05

Input and timing rules

externalId is required and must be a non-empty string. Leading and trailing whitespace is removed.
name is optional. A name supplied without a valid externalId is ignored.
Both values are limited to 255 characters after trimming.
Identity is attached when a new session is created. Calling identify(...) after a conversation has started affects later new sessions, not the active session.
A page-level identity remains in the current widget runtime until it is replaced or cleared. A full page load initializes Stand again, so signed-in sites should identify the current customer each time they initialize the widget.
A visitorIdentity passed through openChat(...) or a Stand card is consumed by that session and does not carry into the next conversation.

06

Availability and prerequisites

Visitor identification is available on every Stand plan.
The Stand installation must have executed on the page before website code calls StandChat.identify(...).
The host website must already know the visitor through its own sign-in or account system.
A developer must be able to change the website JavaScript or the attributes of a supported Stand card.
Only authenticated Stand reps can see the optional page-supplied name in live and completed conversations.

07

Security and privacy boundaries

Do not put passwords, authentication cookies, access tokens, recovery codes, or other secrets in either field.
The feature does not sign a visitor in to Stand and does not verify the website’s account session.
It does not create or update visitor contact details such as email address or phone number.
It does not expose the stable external ID to reps, visitors, History results, or conversation exports.
It does not rename or otherwise modify a conversation that was already created before the identity was supplied.

08

Related features

Stand JavaScript API — The public window.StandChat API lets a website reveal its own chat entry points, inspect responder availability, open Stand with page-specific context, and identify a signed-in visitor.
Private page context — Private page context gives a rep or AI Stand-in facts and instructions from the host page without presenting that context as something the visitor typed.
Stand card — The stand-card web component turns authored page content into a contextual chat invitation with explicit activation, optional visitor input, responder identity, presentation themes, and spotlight behavior.