Reference Site

The reference site is a full, working website your developers copy to embed KeenAgents into your own product. Out of the box it ships everything a consumer-facing app needs: sign-up and email verification, login (with one-time-code challenges), password reset, an account page, and a live agent chat — the chat itself built on the Chat SDK. Rather than assembling these flows yourself, you start from a site where they already work end to end and adapt it to your brand and product.

It is a modern web app — Next.js with the App Router, React, and Chakra UI for components, with typed forms and validation. The chat rides a secure WebSocket through the Chat SDK; everything else — login, token refresh, chat history, profile — goes through the site's own server-side routes, which hold your partner credentials and the consumer's session so the browser never sees them.

Consumer authentication

The full two-token session flow — login, one-time-code verification, and token refresh — already implemented. Session tokens are held in server-set, browser-hidden cookies; the browser never handles the raw tokens.

Account management

Sign-up with email confirmation, forgot-password with an emailed link, a profile page (name, gender, date of birth) that saves partial updates, and a logged-in password change — each already following the claim-then-confirm pattern the platform expects.

The live chat

A chat surface built on the Chat SDK: it opens the connection, sends each turn, streams the reply into a bubble, shows progress rows for a multi-step run, and offers Cancel mid-response. It also renders an agent's tool-call directives as inline chips.

A server-side relay

A set of the site's own server routes that hold your partner credentials and the consumer's session and relay to KeenAgents over HTTPS. The browser only ever calls these local routes, so credentials and raw tokens stay off the client.

A change-notice channel

A receiver for organization-side change notices that reacts in the open browser — signing a consumer out when their access changed (their contract or granted spaces), so the next login picks up the new entitlements, and raising a blocking notice when a space or an agent they may be using was changed. This is the webhook a partner site is expected to accept.

Per-agent front settings

Reads the partner-facing Front Settings an admin defines on each agent (a welcome message, a theme, a title…) by field name, keeps them cached, and refreshes them the moment the admin saves — so the pages can adapt to the agent without a deploy. The agent's runtime Json Settings are never exposed to the site; only scripts see those.

• Sign in — credentials, with a one-time-code step when the tenant requires it, and a "check your inbox" state for reset links.
• Register — a full profile form that starts the sign-up, plus the landing page the emailed confirmation link opens to finish it. Nothing is created until the link is followed.
• Forgot / reset password — the request form and the landing page the emailed link opens to set the new password. The password is unchanged until the link is followed.
• Spaces → agents → conversations → the chat — the consumer's granted spaces, the active agents in a space, the list of conversations with an agent (start, continue, rename, archive), and the chat itself.
• Account — edit profile and change password (a logged-in change is confirmed by email; the live session is proof of identity, so the current password isn't asked).
• Maintenance and not-found — a holding page shown until the connection to the platform is ready, and a catch-all for unmatched URLs.

1. Copy the site and set your credentials. Provide your partner credentials, the platform endpoints, and the space and agent you are integrating. The site reads these from its own configuration; nothing is hard-coded into the pages. Or let an assistant do it: the Keen Mastering Toolkit's /keen-start configures a copy of this site, starts and tunnels it, and registers its Origin for you.
2. Wire and wake it. In the admin console, give your API key a client, a certificate and a consumer contract, allow-list the site's public origin, and set the key's webhook URL to the site's /api/keen-webhook. Then press Wake on the key: the platform delivers the site's certificate and current configuration, and the site switches from its holding page to live. Until that first wake the site deliberately serves nothing.
3. Point the chat at your agent. The chat runs an agent by its slug inside a space; wire your space and agent slug and the conversation is live. Rename a slug and update it here.
4. Rebrand it. Swap the theme, logo, and copy. Because components read from one shared theme, re-skinning is a small, contained change rather than a page-by-page rewrite.
5. Extend it. Add your own product pages around the chat, adjust which request cookies the chat forwards to your flow's script nodes, and accept the change-notice webhook so organization-side changes reach the open browser.

The chat is the same Chat SDK documented on its own page — the reference site is simply a fully-wired consumer of it, so the behavior you read about there is exactly what you get here. If you only want the conversation and already have your own account system, you can lift the chat piece alone and leave the rest.