ChatbyteChatbyte Docs

Pages

Configure, style, publish and embed a branded page for your agent.

Pages gives an existing chat agent its own hosted or embedded conversation page. Each Page belongs to one agent. To publish another agent, configure that agent's Page separately; a Page does not contain an agent picker.

Configure and publish

  1. Open Agent → Deployments → Pages. Overview shows the assigned agent and whether its chat channel and Pages hosting are configured.
  2. Choose Appearance to set the display name, theme and colors. Upload a logo or favicon, or supply an HTTPS image URL. Uploads must be PNG, JPEG, GIF or WebP under 500 KB; Chatbyte stores the resized images in public branding storage. Do not upload private documents as branding assets.
  3. Use Chat experience for welcome text, starter prompts, the composer and attachment settings. Knowledge, tools and agent behavior stay on the agent.
  4. Set Access to public or sign-in required. For an iframe, add each allowed website origin, including https://. Origins are exact, without a path.
  5. Save draft, then Publish saved draft. Saving alone does not change the published Page. Publishing checks the agent's active chat channel and hosting readiness. Unpublish stops visitors accessing the Page.

The style preview uses the actual Page interface with a sample conversation. Changes appear before saving and do not execute the agent. Use its desktop/mobile controls to check the layout, and switch between Welcome and Conversation. Real authentication and conversations are tested by opening the published Page.

Choose an address

  • Managed address: edit the slug in Overview, for example acme-support.chatbyte.page. Save and publish to apply it.
  • Custom domain: enter a hostname such as help.acme.com in Domains and keep Path as /. Add the displayed DNS and ownership records, then check the domain. Select Make primary once verified.
  • Customer subpath: enter acme.com and /support. Your website must run a server-side reverse proxy; DNS cannot route a path. Follow the subpath setup guide and download the tested adapter. Keep the one-time proxy key in your server secret store, along with the connection ID and Page ID. The proxy must route the mount and its descendants plus reserved Pages assets. Verify ownership and the proxy connection before making it primary.

Install displays the full address, including a subpath, and uses the published access policy. Save and publish draft access changes before copying updated code. A custom domain and a subpath use the same Page and agent. Removing a connection revokes its routing; replacing a proxy key requires updating your server and verifying again.

Embed a public Page

Copy the iframe from Install and put it in your site. Add your site's origin under Access. Adjust the iframe's width and height to fit your layout. A public Page needs no authentication SDK.

Private Pages

Your existing backend remains responsible for authenticating the user and authorizing their current account. This works with your own sessions or a provider such as Auth0. Configure an RSA public key of at least 2048 bits, issuer, backend sign-in URL, audience (customer or workforce), and any required roles in Access. Keep the private signing key on your backend.

Hosted Page: clicking sign-in opens your configured backend URL with a challenge. Authenticate the user, validate the challenge, and return the proof to the opening Page using postMessage with its exact origin. The Page exchanges the proof for its own HttpOnly session cookie. Do not put proofs in redirect URLs.

Embedded Page: Install supplies the iframe and Pages module connection code. Implement the /pages/proof endpoint referenced by that code. It receives the challenge, authenticates the current backend session and returns { proof }. Enforce the requesting website origin and do not cache this response. The SDK keeps the resulting Page credential in memory and renews it using fresh proofs.

The challenge contains nonce, pageSurfaceId, pageOrigin, and, for embeds, parentOrigin. Validate all of them against your configured integration. Sign a short-lived RS256 JWT with these claims:

ClaimValue
issThe issuer configured in Access
subThe stable user ID from your verified backend session
audchatbyte:pages:<pageSurfaceId>
iat, expCurrent time and a short expiry, for example 60 seconds
nonce, pageSurfaceId, pageOrigin, parentOriginThe validated challenge; omit parentOrigin for hosted login
audienceKindThe configured customer or workforce audience
accountId, rolesThe active account and authorized roles from your backend

Never take the subject, account, roles or audience from an untrusted proof request. For hosted login, send this message to window.opener with pageOrigin as the target origin, then close the popup:

window.opener?.postMessage(
  { source: 'chatbyte-pages-host', type: 'pages.auth.proof', nonce, proof },
  pageOrigin,
);
window.close();

For an embed, call connection.logout() when the user logs out, connection.refresh() after an authorized login or account switch, and connection.destroy() when removing the integration. Hosted sessions expire independently. After logout(), automatic iframe sign-in stays stopped until your application explicitly calls refresh() for an authorized viewer. Logging out of your website does not automatically send a logout event to another open Page tab. Private Page sessions expire after 15 minutes.

Before releasing a private integration, test account switching, expired sessions, logout, rejected roles and reopening an existing conversation with your real identity provider. Never forward the provider's access token as a Page proof.

On this page