A customer who is signed in to your website has already told you who they are. Then they open the chat and become a stranger again. They are asked for an order number they could have been shown, they repeat a preference they gave last week, and they lose the conversation they started on their phone when they switch to their laptop.

Recognising signed-in visitors fixes all of that. It is also the part of a chatbot that is easiest to get dangerously wrong. A chatbot that believes the wrong person can show one customer's orders to another. Gydr 4.0 rebuilds visitor identity around one token and a short list of rules we will not bend.

One token, checked by Gydr

Your site already issues something for a signed-in user: an API token, a token from your identity provider, or one your own server signs. In Gydr 4.0, the widget needs only that. Your page hands it over, and Gydr checks it in one of the three ways you choose in Settings → Visitor sign-in.

The Add sign-in source panel, offering WordPress or WooCommerce, Your keys and Your backend, with Shopify marked as coming soon.
Three ways for Gydr to check a visitor's token.

WordPress uses the Gydr plugin, which signs your visitors in with its own key and needs no code editing. Your keys checks the token's signature with your identity provider's public keys, or with a key pair of your own. Your backend works with any token: Gydr asks your server, in a signed request, who the token belongs to.

A visitor whose token checks out carries your own User ID for them. It appears on the visitor's row in the Console, in webhooks, in the Conversation API, in Custom Desk and in exports, and you can search conversations by it. Settings → Visitor sign-in also has a tester that runs the real check on a token and shows you the User ID, or the exact reason it was not recognised.

The person, on every device

Once a visitor is recognised, their conversations follow them on every device, including conversations through the Conversation API. Their visitor memory is on automatically, unless you have turned conversation history off.

Plugins that call your REST API, your MCP server, Shopify or WooCommerce on the visitor's behalf receive the same token, and only on the address it belongs to. A token issued for your store is never sent anywhere else.

The rules underneath

Getting identity right is mostly about what the system refuses to do. These are the rules Gydr 4.0 is built on.

Gydr makes every visitor ID. A page, a link or an API call can no longer choose one. Someone who guesses or copies an ID gets nothing, because the ID alone proves nothing.

Every change of person starts fresh. Signing in, signing out or switching person always starts a new visitor. A guest's conversation never carries into a sign-in, so nobody inherits a chat that was not theirs.

An outage never signs anyone out. If your sign-in check is briefly unreachable, nobody is signed out of a conversation they are in the middle of.

The chat never asks you to prove who you are. There are no one-time codes and no magic links typed into the conversation. Identity comes from the sign-in your site already trusts, never from what someone types to a chatbot.

Two sources never mix. If two sign-in sources happen to return the same ID, they are still two different people.

Why we made it a major release

Identity changes are the kind most platforms postpone, because they break things. This one did. Some older setups stopped working, and we listed each one with its replacement on the migration page. We think that was the right trade. A chatbot that knows its customers is far more useful. A chatbot that can be fooled into knowing the wrong one is a liability, and no amount of convenience is worth that.

Frequently asked questions

How does Gydr recognise a signed-in visitor?

Your page hands the widget the token your site already issues, and Gydr checks it in one of three ways: the WordPress plugin, your identity provider's keys, or a signed request to your own backend.

Will the chatbot ask visitors to prove who they are?

No. There are no one-time codes or magic links in the chat; identity comes only from the sign-in your site already trusts.

What happens if the sign-in check is briefly unavailable?

Nobody is signed out of a conversation they are in the middle of.

The full list of changes is in the 4.0.0 release notes.