Signed-in customers in the chat widget

By default the chat widget treats every visitor as a guest: they type a name and an email address, and nothing proves who they are. Customer identity adds two ways for a visitor to be recognised, and shows your team how each conversation was identified.

• Your application vouches for the customer. If the visitor is already signed in to your own application (a shop, a customer portal, a SaaS product), that application confirms the account to the widget with a short-lived, signed assertion. The visitor skips the name and email form and sees their earlier conversations from that account.
• Email code. The visitor enters an email address, receives an eight-digit code and signs in with it. This proves control of the mailbox right now, not who the person is.

Both are optional. Guests keep working exactly as before.

What your team sees

In the inbox, a customer-owned conversation shows how the person was identified, directly under the subject:

• Identified via application, with the integration that vouched for the account and when it last did so. A name or email shown there was asserted by your application.
• Email address confirmed by code, with the confirmed address.

This is a record of the proof method, not a statement that the person is who they claim to be. Treat sensitive requests (orders, account changes) with the same care as before: an application sign-in proves an account in that application, and an email code proves a mailbox.

Setting up application sign-in

You need to be the owner of the organization. Go to Settings → Customer identity.

1. Create an integration. Give it a name and list the exact origins of your application, one per line, for example https://shop.example. Only pages served from these origins can sign customers in. Each integration gets an issuer identifier that your application puts into every assertion.
2. Register a public key. Your application signs assertions with an RSA key pair that it generates itself. Paste only the public key here. The private key stays on your server; we never ask for it, and you should never paste it anywhere. Keys are 2048 to 4096 bits.
3. Connect your application. Follow the developer integration guide. It includes Python and Node examples. Your assertion endpoint must read the current signed-in account from your application's own server-side session, sign a short-lived assertion, and return it only to that same browser session. Configure the widget loader to call this endpoint. Never create the assertion from a user ID the browser sends.

Rotating or revoking a key

To rotate, register the new key with an overlap of one to seven days. During the overlap both keys are accepted so you can switch your application over; afterwards the old key stops being accepted for new sign-ins. Revoking a key immediately signs out every customer whose session was created with it. Revoke all sessions or Disable sign out every customer of the integration at once; disabling also stops new sign-ins until you enable it again.

How long a sign-in lasts

An application sign-in lasts 15 minutes and is renewed in the background while the widget is open. When the customer signs out of your application, your page calls the widget's logout(); the widget forgets the account and tells the other tabs on your site to do the same. A missed call is bounded by the 15-minute lifetime.

Email code sign-in

Email sign-in is a setting of the widget: Settings → Channels → Chat widget, switch on Offer email-code sign-in. Two conditions apply:

• The widget's allowed origins must be exact HTTPS origins such as https://shop.example. Entries with a path, a trailing slash or capital letters are refused when enabling.
• You must acknowledge the limitation of email as proof: everyone who can read a mailbox (shared, forwarded, reassigned or compromised addresses) can see that email identity's conversation history. Keep sensitive account or order details behind your application's own sign-in or your connector checks.

Email sessions end after 30 minutes without the customer doing anything, and after eight hours in any case. Codes are valid for ten minutes; a visitor has five attempts per code and can request a new code after a one-minute pause.

Privacy and data

• Sign-in credentials are kept in the widget's memory only, never in browser storage or in a URL. Closing the tab removes the browser's credential; the server session expires under its 15-minute application or 30-minute idle/eight-hour email limit.
• Your application's private key, the signed assertions and the email codes are never stored by us and never appear in logs.
• An application account and an email identity with the same address are not linked automatically, and neither claims conversations that a guest had earlier. Deleting the organization removes its customer records together with its conversations.