Recognise logged-in users

If customers sign in to your website or app, the widget can know who they are. Your team then sees the customer's name and email in the Inbox without asking, the contact details form is skipped, and the customer finds the same chat history on their laptop, phone and your app. This needs a little work from your developer; this article explains what it does and what you hand over.

What your team sees

When your website tells the widget who the visitor is, the visitor's card in the Inbox shows one of two badges:

The difference matters for privacy:

• A verified visitor is linked to their customer profile. Every browser and device where they are signed in shares one conversation history.
• An unverified visitor stays separate. If they use an email or phone that belongs to a customer who signs in on your website, they are not linked to that customer and do not see their history or receive their replies. This stops someone from typing another customer's email to read their chats.

Agents can still merge two customers by hand after checking. See Merge customers.

Get the identity secret

Each website has its own identity secret. Your developer uses it on your server to sign the user, so that only your website can produce a Verified visitor.

1. Go to Customer Support → Channels and click your website.
2. Scroll to Identity secret and click Rotate & reveal.
3. The secret appears once, at the top of the page. Copy it and send it to your developer through a safe channel, such as your password manager.

Ha Tang does not show the secret again. If you lose it, or think it has leaked, click Rotate & reveal again and give your developer the new one. From that moment the old secret stops working: signed-in users show as Unverified until your website uses the new secret. Visitors already linked keep their profile and history.

What your developer does

Your developer:

1. Computes a signature of the user's ID with the identity secret on your server.
2. Sends the user's ID, name, email and the signature to the widget each time a signed-in user opens a page.
3. Resets the widget when the user signs out, so the next person on the same computer does not see their chats.

The developer guide has the details and code in several languages: Identity verification. Mobile apps use the same secret through the SDKs.

Check that it works

1. Sign in to your website (or app) with a test account, then send a message from the widget.
2. Open that conversation in Customer Support → Inbox. The customer card on the right should show the account's name and email and the Verified label.
3. Open the widget in another browser or device and sign in with the same account: the earlier chat history should be there.
4. Sign out and open the widget again: the account's conversations should no longer show.

If the card still says Unverified, the signature doesn't match. Usually the secret belongs to another website, the secret was regenerated, or a different ID was signed (the signed ID must be exactly the ID sent to the widget). Point your developer to the troubleshooting part of Identity verification.

On WordPress

The Ha Tang Chat plugin sends the name and email of logged-in WordPress users for you, marked Unverified. To get Verified users, your developer adds a few lines to the theme that sign the user with the identity secret, kept in wp-config.php. See Install the widget on WordPress.

Open the customer in your admin

With the user id your website sends, agents can jump from a conversation straight to that customer in your own admin, for example https://tatca.ai/admin/users/{{user_id}}. Links built from a verified id are trusted; without identity verification they carry a warning. See Open the customer in your own admin.

Extra details for your team

Your website can also send details your agents find useful, such as the customer's plan, number of orders or customer number. They appear under Attributes in the customer panel, next to the Journey of pages and events that led the customer to write. Ask your developer to send only what the team needs, never passwords or card numbers. See Show your team what customers did before writing.