Guests & Data Never to Send — Documentation

On this page

Guests & Data Never to Send
The rules
Passing unverified details the safe way
Ready to get started?

Guests & Data Never to Send#

Gydr treats every claim in an identity token as something your server vouches for — 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 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.identify({ name, email }) or the data-visitor-* attributes. They are used for greetings and hand-off to your team only.
Never: Put it in the identity token.
Why: Anyone can type any email into a form. Only a signed-in session on your site proves ownership.

Situation: Visitor id
Do: Let the widget generate it.
Never: Set visitorId or data-visitor-id to a user id, an email, or anything else guessable.
Why: The visitor id is a label anyone can pick, not proof. A guessable one lets a stranger open a conversation under your user's label.

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 ids and details a connected plugin needs.
Never: Passwords, addresses, payment details, session cookies, or other systems' tokens.
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 secret in server config (wp-config.php, environment variables).
Never: Sign in browser JavaScript, send the secret to the page, or commit it to a code repository.
Why: Whoever holds the secret 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 second key, deploy it, then retire the first.
Never: Keep using a key you believe leaked.
Why: Retiring the 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.identify({ name, email })` or the `data-visitor-*` attributes. They are used for greetings and hand-off to your team only.	Put it in the identity token.	Anyone can type any email into a form. Only a signed-in session on your site proves ownership.
Visitor id	Let the widget generate it.	Set `visitorId` or `data-visitor-id` to a user id, an email, or anything else guessable.	The visitor id is a label anyone can pick, not proof. A guessable one lets a stranger open a conversation under your user's label.
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 ids and details a connected plugin needs.	Passwords, addresses, payment details, session cookies, or other systems' tokens.	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 secret in server config (`wp-config.php`, environment variables).	Sign in browser JavaScript, send the secret to the page, or commit it to a code repository.	Whoever holds the secret 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 second key, deploy it, then retire the first.	Keep using a key you believe leaked.	Retiring the 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 — never inside the token:

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

Ready to get started?

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

Contact sales →