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
- Open Agent → Deployments → Pages. Overview shows the assigned agent and whether its chat channel and Pages hosting are configured.
- 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.
- Use Chat experience for welcome text, starter prompts, the composer and attachment settings. Knowledge, tools and agent behavior stay on the agent.
- Set Access to public or sign-in required. For an iframe, add each allowed
website origin, including
https://. Origins are exact, without a path. - 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.comin 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.comand/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:
| Claim | Value |
|---|---|
iss | The issuer configured in Access |
sub | The stable user ID from your verified backend session |
aud | chatbyte:pages:<pageSurfaceId> |
iat, exp | Current time and a short expiry, for example 60 seconds |
nonce, pageSurfaceId, pageOrigin, parentOrigin | The validated challenge; omit parentOrigin for hosted login |
audienceKind | The configured customer or workforce audience |
accountId, roles | The 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.