Skip to main content
The widget works behind a login exactly as it does on a public page — it is a script tag either way. The real question is what the agent knows about the person who is logged in. The answer is a division of labour: Animam never authenticates anyone. It receives an identity your system has already proven, then asks your system for that person’s data. You stay the authority on both.

Three layers, adopt them in order

Each layer stands alone. Identity alone already gives you memory that follows the person rather than the browser.

1. Get your signing key

The key is returned once and never readable again — store it in your backend secrets. Regenerating it invalidates every token already issued. It must never reach the browser: it signs identities, so anyone holding it can impersonate any of your users.

2. Sign a token for the logged-in user

Do it server-side, when you render the page. Nothing here is Animam-specific — it is a plain HS256 JWT.
Use your internal id as sub, not the email: it is what ties the visitor to a stable record even when they change address. Animam checks the signature, the presence of sub and iat, and the expiry — defaulting to iat + 24h when you omit exp. An invalid or expired token is not an error: the visitor is simply treated as anonymous, and the conversation continues.
The token sits in your page’s HTML, so treat it as visible to any script on that page: keep the claims minimal and the lifetime short. It also cannot be revoked — logging out does not invalidate a token that is still within its exp. An hour is a good default.

3. Hand it to the widget

The widget sends it as the X-Visitor-Token header on every message. Animam verifies it and resolves — or creates — the matching VisitorUser, keyed on sub (or email when it matches an existing record). From there, everything the agent remembers about that person follows them across browsers and devices. Restrict allowedDomains on your tenant to your own origins while you are at it: the widget then refuses to answer from anywhere else.

4. Serve the visitor’s record

Point the tenant at an endpoint you own:
On every message from an identified visitor, Animam POSTs to it:
Verify the signature over the raw body, then answer with free text — you decide what the agent is allowed to know:
The text is injected into the agent’s prompt for that conversation.
Scope the query to the identified visitor, and to them alone. Animam relays what you return — it cannot tell one customer’s data from another’s. Send only what you would accept the agent saying out loud, and never tokens or credentials.

Optional: a second factor

If reading the record is not enough proof for a sensitive request, return a challenge alongside the context:
The agent relays your prompt, then POSTs the visitor’s answer to verifyUrl (same HMAC signature, 10 s timeout). Reply { "verified": true, "context": "…" } to unlock more, or { "verified": false, "message": "…" } to refuse. You own the factor and the verdict; Animam only carries the conversation.

5. Let the agent act

Reading is half the job. To cancel a subscription, release an invoice or update a preference, declare a verified action: Animam POSTs to your endpoint carrying the server-verified email — never an address the model produced. A JWT identity qualifies, exactly like a one-time code does. For a broader surface, plug in your own MCP server and the agent discovers your tools directly.

What this costs you, in plain terms

What Animam stores

Conversations, VisitorUser profiles and the facts the agent remembers are stored on Animam’s infrastructure. The record you return through the webhook is not persisted — it is fetched per conversation and injected into the prompt. Plan for this in your privacy notice; a DPA is available at contact@animam.ai.