Guests & Data Never to Send — Documentation

On this page

Guests & Data Never to Send
The rules
Passing unverified details the safe way
When a human team needs details or a signed-in visitor
Ready to get started?

Guests & Data Never to Send#

Gydr treats the visitor token as something your site vouches for — Gydr recognises the person from it and plugins act on it to show a person their own orders and account details. That makes the token powerful, and a mistake in what you put in it, or in who you hand it to, can show one person’s data to another. These rules keep that from happening.

The rules#

Situation: Visitor is not signed in
Do: Return null from your endpoint or provider.
Never: Sign a token for a guest, or hand out another user's token.
Why: A token is proof of who someone is. A guest has nothing to prove, and a borrowed token shows them someone else's data.

Situation: You know who someone is, but haven't verified it (a newsletter email, a form they filled in)
Do: Pass it as ordinary visitor details: Gydr.setVisitorDetails({ name, email }) or the data-visitor-* attributes. They are used for greetings and hand-off to your team only.
Never: Hand it over as a visitor token.
Why: Anyone can type any email into a form. Only a signed-in session on your site proves ownership.

Situation: Visitor id
Do: Nothing. Gydr makes the visitor id; you cannot choose one.
Never: Try to put a user id, an email or anything else in a visitor id — through a link, storage or the API.
Why: A visitor id chosen by a page would be a label anyone could pick. Because Gydr makes every id and checks a proof for a signed-in one, a stranger cannot open a conversation under your user's id.

Situation: Email in the token
Do: Set email_verified: true only when your site confirmed the address (for example with a confirmation link).
Never: Send email_verified: true for an address nobody checked.
Why: Plugins match records by a verified email. An unchecked one could match a stranger's account.

Situation: Claims
Do: Only the user id and the few details (name, email) you want Gydr to know.
Never: Passwords, addresses, payment details, session cookies, or other systems' tokens inside your own token.
Why: The token passes through the browser. Keep it small and free of anything that would harm someone if copied.

Situation: Signing
Do: Sign on your server, with the private key in server config (environment variables, a secrets manager). Gydr only ever holds your public key.
Never: Sign in browser JavaScript, send the private key to the page, or commit it to a code repository.
Why: Whoever holds the private key can sign in as any of your users.

Situation: Caching
Do: Serve the token from an endpoint no cache stores.
Never: Print the token into HTML that a page cache or CDN can store.
Why: The cache would serve one customer's token — and their orders — to the next visitor.

Situation: Sign-out
Do: Nothing extra: your endpoint returns null and the widget clears the conversation.
Never: Keep serving a signed-in token after the person signed out.
Why: The next person on that browser would inherit the account.

Situation: A secret may have leaked
Do: Create a new key pair (or rotate the backend secret, which keeps everyone signed in while both work), deploy it, then retire the old one.
Never: Keep using a key you believe leaked.
Why: Retiring the old key makes every token signed with it worthless.

Situation	Do	Never	Why
Visitor is not signed in	Return `null` from your endpoint or provider.	Sign a token for a guest, or hand out another user's token.	A token is proof of who someone is. A guest has nothing to prove, and a borrowed token shows them someone else's data.
You know who someone is, but haven't verified it (a newsletter email, a form they filled in)	Pass it as ordinary visitor details: `Gydr.setVisitorDetails({ name, email })` or the `data-visitor-*` attributes. They are used for greetings and hand-off to your team only.	Hand it over as a visitor token.	Anyone can type any email into a form. Only a signed-in session on your site proves ownership.
Visitor id	Nothing. Gydr makes the visitor id; you cannot choose one.	Try to put a user id, an email or anything else in a visitor id — through a link, storage or the API.	A visitor id chosen by a page would be a label anyone could pick. Because Gydr makes every id and checks a proof for a signed-in one, a stranger cannot open a conversation under your user's id.
Email in the token	Set `email_verified: true` only when your site confirmed the address (for example with a confirmation link).	Send `email_verified: true` for an address nobody checked.	Plugins match records by a verified email. An unchecked one could match a stranger's account.
Claims	Only the user id and the few details (name, email) you want Gydr to know.	Passwords, addresses, payment details, session cookies, or other systems' tokens inside your own token.	The token passes through the browser. Keep it small and free of anything that would harm someone if copied.
Signing	Sign on your server, with the private key in server config (environment variables, a secrets manager). Gydr only ever holds your public key.	Sign in browser JavaScript, send the private key to the page, or commit it to a code repository.	Whoever holds the private key can sign in as any of your users.
Caching	Serve the token from an endpoint no cache stores.	Print the token into HTML that a page cache or CDN can store.	The cache would serve one customer's token — and their orders — to the next visitor.
Sign-out	Nothing extra: your endpoint returns `null` and the widget clears the conversation.	Keep serving a signed-in token after the person signed out.	The next person on that browser would inherit the account.
A secret may have leaked	Create a new key pair (or rotate the backend secret, which keeps everyone signed in while both work), deploy it, then retire the old one.	Keep using a key you believe leaked.	Retiring the old key makes every token signed with it worthless.

Passing unverified details the safe way#

Details you know but can’t vouch for still help the chatbot greet a visitor by name and give your team context when a conversation is handed over. Pass them as ordinary visitor details:

<script
  src="https://cdn.infinichat.dev/widget.js"
  data-api-key="pk_live_YOUR_KEY"
  data-visitor-name="Siti"
  data-visitor-email="siti@example.com"
  async
></script>

When a human team needs details or a signed-in visitor#

Two settings decide whether a visitor can reach a human team at all, and both are checked when you save in the Console, so a team that could not work is never offered to visitors:

Required details. Some desks refuse to work without a visitor field (for example, a live chat that needs the visitor’s name and email). For every mode you turn on, those fields must be both enabled and required in the widget’s visitor details. An optional field is not enough, and Gydr tells you which field to change.
Signed-in visitors only. A team can be limited to signed-in visitors. That needs a sign-in source on the widget, and while a team needs one you cannot remove it. A guest never sees such a team, even when it is the only one.

Details a visitor typed are used to reach your team (and to prefill a ticket’s email); they never count as proof of who the visitor is.

Ready to get started?

Create a free account and deploy your first chatbot in minutes.

Contact sales →