Administering portals

This guide takes you from an empty list to a configured portal and then through every tab of the portal page: agents, access, network restriction, appearance and browser tab, chat features, compliance, announcements, limits, change history, duplicate / export / import, test sessions, statistics and the Embed summary. For what the people who use a portal see, read Using a portal; for routes, payloads and error codes, read the administration API and reference.

Enterprise module

Portals are part of the enterprise edition. Without an active enterprise license the dashboard shows an upgrade prompt and the administration and chat routes answer 402. See Licensing.

Who can administer portals

Only a workspace owner or admin can create, change or delete a portal, open one as a test, or read its history and statistics. Reading what people said in a portal (the Conversations tab) is a separate permission, portal.conversations_view, also held by owners and admins by default (see Conversations). The role is read from the user record on every request, so a session that is days old does not keep rights the person has lost. Custom RBAC roles are deliberately not accepted here, however broad their service permissions: a portal's access list decides who can reach agents of the whole workspace, so managing portals is not delegated.

People who use a portal need none of this. They need no project membership and get no dashboard access; they sign in with their own account and the portal's access list decides the rest.

The Portals list

Open Operate → Portals. The list shows every portal in the workspace.

Column	Meaning
Portal	Name and description.
Link	The address /p/{address} with a copy button.
Agents	How many agents the portal offers.
Who can use it	Everyone, Nobody (selected, but nobody chosen), or n groups, n users.
Status	Enabled or Disabled.
Conversations (7d)	Conversations active in the last seven days. Test sessions are not counted.
Last used	When anyone last used the portal (test sessions excluded).

Filter by name or address with the search box. Press a row to open the portal page. The row menu has Go to portal (opens the chat in a new tab), Details, Edit, Statistics, Duplicate and Delete. The page header has Create portal and Import settings.

Create a portal

Press Create portal. The form is a full-screen overlay with five sections.

1. Basics

Field	Default	Rules and effect
Name	—	Required, up to 120 characters. Used as the header title unless you set one under Appearance.
Portal address	Generated	3 to 48 characters: lowercase letters, digits and hyphens, starting with a letter or a digit. Must be unique in the workspace (The address "x" is already used by another portal). Leave it empty to get 8 characters from an alphabet without look-alike glyphs (no i, l, o, u, 0, 1).
Description	—	Up to 500 characters. For administrators: it is shown on the Overview tab.
Welcome text	—	Up to 4,000 characters, Markdown. Shown on the empty chat. See Welcome message and starters.

The link preview under the form shows the final address. There is no workspace in the address: https://console.example.com/p/hr-desk is the same link for everybody, and the workspace is taken from the person's session.

Changing the address breaks shared links

When you edit an existing portal, changing the address makes every link you already shared stop working. The form warns you before you save.

2. Agents

Pick agents from the searchable list, grouped by project. Only agents that are active and have a published version appear. Use the arrows to reorder; the first agent is the default when someone opens the portal. See Agents in a portal.

3. Who can use it

Choose Everyone in the organization or Selected people, then pick groups and people. See Access.

4. Chat details

Field	Default	Effect
Language	English	English or Türkçe. Everybody who opens this portal sees the page and chat in this language, whatever their browser or Console language is.
Show tool arguments	On	Approval requests and tool progress show the inputs of a tool call (a query, a file path) so people can see what they approve. Turn it off if inputs can contain internal identifiers the audience should not read.

5. Status

Enabled (default) or Disabled. A disabled portal shows a friendly "unavailable" page to people who would otherwise be allowed in.

Press Create portal. The confirmation screen shows the link with a copy button and Open portal. A new portal starts with the recommended chat features already on.

Choosing "Everyone" in the form versus the API

In the dashboard form the default access is Everyone in the organization. When you create a portal through the API without an access field, the portal starts as selected with nobody on the list, which admits nobody. The safe direction wins whenever the input is missing or unclear.

The portal page

Press a portal in the list to open its page. The header shows the name, status and link, Go to portal, Edit and a … menu.

Menu entry	What it does
Disable / Enable	Switches the portal off or on after a confirmation. Conversations are kept.
Open as test	Opens the portal for you in a marked test session.
View as…	Jumps to the Access tab's View as check.
Change history	Jumps to the History tab.
Duplicate	Makes a disabled copy. See Duplicate, export and import.
Export settings	Downloads the settings as a JSON file.
Import settings	Replaces this portal's settings from a file.
Delete	Deletes the portal after a confirmation.

The tabs, in order: Overview, Appearance, Chat features, Compliance, Announcements, Access, Embed, Limits, Statistics, Conversations, Usage and History.

The Overview tab shows the last seven days at a glance (conversations, messages, active users, tokens and cost), the description and welcome text, the agents with their published version, who can use the portal, and the activity (last used, created and updated, with who did it).

How saving works

The Edit form saves the basics (name, address, description, welcome text, agents, access, language, tool arguments, status). The other tabs each have their own Save and Reset:

• A tab you have edited shows an amber dot until you save it. Unsaved edits stay in the tab while you look at another one, and leaving the page (reload, close, typing another address) asks for confirmation.
• A tab saves only what it owns. Saving Limits never touches Compliance.

Agents in a portal

A portal offers up to 50 agents. Each agent key can appear only once in a portal, because the chat addresses agents by key.

• Eligibility. An agent can be added only when it exists, is active, and has a published version (Agent "x" has no published version (or is not active) and cannot be added).
• Always the published version. The portal runs the version you published, not the draft. Publish again for changes to reach people. This also applies to the agent's own settings that shape the portal experience:

Where, on the agent	Effect in a portal
Files	The paperclip appears only when files are switched on and a bucket that works is chosen. Size, count, types and retention limits come from here.
Approvals & questions	Whether the agent pauses to ask for tool approvals or answer questions, who may answer, how long a request stays open, and what a new message does while one is open.
Usage limit	The per-conversation spend limit and whether people may raise it or continue after it is reached.

• After an agent changes. If an agent is unpublished, disabled or deleted after you added it, the Overview tab shows a Not published or Agent not found badge and the portal skips it for people. An unrelated edit to the portal is not blocked by it.
• Per-agent welcome and starters. The Chat features tab lets you override the welcome message and the starter questions for each agent. See below.

Access

The Access tab has four cards that work together: who can use the portal, the policies that also apply, the network restriction and View as.

Who can use this portal

The access list is the portal's built-in rule:

Mode	Meaning
Everyone in the organization	Any signed-in person of the workspace can open the portal and run its agents.
Selected people	Only the groups and people you list. Selected with no group and no person means nobody, and the form warns you.

Pick people and groups with the searchable pickers; a workspace can have tens of thousands of people, so nothing loads them all. Edit access opens the form scrolled to this section. The card summarises the audience, for example "1 people and 0 groups".

Three consequences are worth knowing:

• Using a portal does not give access to Console. People always sign in with their own account.
• Being on the list is required, whatever the role. A workspace owner who is not on the list cannot open the portal either, except in a marked test session.
• API tokens cannot open portals or run agents through them. Choose a person.

Policies that also apply

The list is the portal's built-in policy. Policies in the authorization center (IAM) can restrict it but never widen it:

• A deny rule can still block a person, a group or a single agent, even if they are on the list.
• An allow rule does not add people to a portal ("Allow rules do not add people to a portal").
• The card lists the policies that mention this portal with their scope (This portal or All portals) and whether they are disabled. Use Block someone… to start a deny rule, Check a person to run an access check, and Open IAM to go to the authorization center. Policies are visible only to people who can read IAM.

Each time a person is refused by the engine, they see a reference code. Paste it into IAM center → Access check → Look up a denied request to see the decision and the rule behind it. How the engine decides, and how to write deny rules for portals, is covered in Portal access boundaries and Custom policies.

Network restriction

Limit where the portal can be used from. When it is on, everyone is checked against the address their requests come from: signed-in people, people using the embedded chat, and administrators trying the portal in a test session.

Setting	Default	Detail
Allowed networks	Any network	Choose Only these networks to turn the restriction on.
IP ranges	—	IPv4 or IPv6 ranges in CIDR form (203.0.113.0/24, 2001:db8::/32) or a single address (198.51.100.7). Up to 32 ranges per portal; fold neighbouring ranges into larger ones. IPv4 addresses written inside IPv6 (mapped addresses) are not accepted.
Message for people outside these networks	Default text	Up to 300 characters. Shown with the reference code on the refusal page.

Rules to keep in mind:

• An allow-list needs at least one range; an empty one would lock everybody out, so it cannot be saved.
• A request with no readable address is refused too. Nothing overrides the restriction: not the access list, not a test session.
• The restriction applies to opening the portal, running its agents and answering their approvals.

Check your own address before you save. The Check your own address panel shows the address as Console sees it for you and says whether the draft ranges would let you in (it checks the draft, not the saved setting). Check another address tests any IP against the draft. You can always change the setting from the dashboard even when the portal would refuse you, because the dashboard is a different door.

Behind a reverse proxy

Console decides on the address it can trust. Behind a reverse proxy or load balancer, set TRUSTED_PROXIES to the proxy's address so the real client address is used; otherwise every person looks like the proxy and "Check your own address" will say so.

A person outside the ranges sees Not available from here, with your message and a reference code.

Appearance and browser tab

The Appearance tab has the look of the page and, below it, the browser-tab settings. Both have a live preview of the chat in light and dark.

Theme

Setting	Default	Detail
Colour scheme	System	System follows each person's device and switches live; Light or Dark fixes it.
Light theme	chatgpt-light	One of chatgpt-light, snow, arctic, cloud, pearl, sky, sandstone, rose-garden, mint, lavender.
Dark theme	midnight	One of midnight, ocean, purple-haze, sunset, emerald, onyx, nord.
Accent colour	The theme's own	Optional #RRGGBB that overrides the accent of both themes (buttons, highlights).

Branding

Setting	Default	Limits
Logo	None	PNG, JPEG, SVG or WebP up to 256 KB; square images look best. An SVG that contains scripts, event handlers, foreign content, external references or a DOCTYPE is rejected rather than cleaned.
Header title	The portal name	Up to 80 characters.
Notice under the input	The default AI notice ("AI can make mistakes. Check important information.")	Up to 300 characters. Replaced by the AI label and legal links once you set them under Compliance.

Browser tab and link preview

Setting	Default	Limits
App name	The header title	Up to 60 characters. Shown in the tab and when the page is added to a home screen.
Page description	—	Up to 300 characters.
Icon	—	PNG, SVG or ICO up to 256 KB. Square.
Home screen icon	—	PNG up to 256 KB; 180 by 180 pixels works best.
Link preview image	—	PNG or JPEG up to 1 MB; 1200 by 630 pixels works best.

Uploaded images must really be the type they claim (the bytes are checked, not just the declared type). They are stored with the portal, served from /api/portal/{address}/assets/... to people who may open the portal, and cached against a content fingerprint, so replacing an image takes effect at once.

Link previews

The icon, app name and description are written into the page's head after the signed-in page has loaded. Link-preview crawlers cannot sign in, so they do not see them, and the images are private to the people who may open the portal.

Chat features

The Chat features tab decides what people can do in the chat. Every switch is stored per portal.

Legacy portals

A portal created before this tab existed has none of these features on. The tab says so ("This portal was created before chat features existed, so none of them are on yet") and saving it turns the chosen features on. Until then, even a request through the API for a feature that is off (renaming a conversation, say) is refused with 403 action_disabled.

Group	Switch	New portal	Effect
Message actions	Copy an answer	On	A copy button on every answer.
	Regenerate the last answer	On	Asks the agent again for the newest answer. Counts against the person's budget like a new question.
	Edit and resend a message	On	People can change one of their messages; everything after it is removed and the agent answers again.
Conversation history	Rename conversations	On	Inline rename. An empty title gives the generated title back.
	Pin conversations	On	Pinned conversations list first.
	Delete several at once	On	Select up to 100 conversations and delete them together; people can only delete their own.
Conversation titles	Write titles with	The agent's own model	Do not write titles, The agent's own model, or A specific model. See below.
Answer feedback	Let people rate answers	On	Thumbs up or down, with reasons when it is down.
	Allow a written comment	On	A comment of up to 1,000 characters. Needs rating on.
Export a conversation	Let people export	On	Markdown, JSON or a printable page. Every export is recorded.
	Include tool calls in exports	Off	Tool inputs and outputs can contain internal details, so they are off by default. Needs export on.
Background alerts	Show a counter in the tab title	On	(1) in front of the tab title while the tab is hidden and something happened.
	Play a short sound	Off	A quiet two-note chime. People can mute it in the bell menu.
	Desktop notifications	Off	Offer to people (they enable it in the chat menu) adds a toggle; the browser asks permission only when the person turns it on themselves.
Links that open a question	Send the question automatically	Off	See Deep links.

Conversation titles

After the first answer, a short title (at most 6 words, in the language of the conversation) is written by a model. Choose:

• Do not write titles: a conversation keeps the first words of the first message.
• The agent's own model: the model the agent uses. An agent that runs outside Console (an external agent) has no model of its own to use, so its conversations keep their first-message title.
• A specific model: pick a language model (category llm) that exists in the project of at least one of the portal's agents. The picker lists the models of those projects; saving fails with Choose a language model that exists in the projects of this portal's agents otherwise.

Writing a title is a small model call. It is recorded like any other (a usage row tagged purpose: title), counted to the person who started the conversation, and it never fails the conversation: any problem simply means no generated title. The model sees only the first exchange, each side cut to 700 characters. While a title is being written the conversation is listed without one.

Feedback

When rating is on, a thumbs-down opens a sheet with the reasons Inaccurate, Incomplete, Off topic, Too long, Unsafe and Other, plus an optional comment. Builders see ratings in Studio, on the agent's Feedback tab (counts, reasons, latest comments with a link to the session) and on the session's messages. A feedback.recorded webhook event carries identifiers and small fields, never the comment.

Comments are readable by people who can edit the agent

Turn Allow a written comment off if people might type personal data into it.

Deep links

A link of the form /p/{address}?agent={agentKey}&q={text} opens the portal on that agent with the question typed into the box. The agent must be one the person can open; otherwise the chat opens on its first agent. The text is plain text, control characters are dropped and it is cut at 2,000 characters.

&send=1 sends the question straight away only when Send the question automatically is on. It is off by default so a link someone else made cannot make a person ask something they did not choose. Turn it on only for links you control. The tab shows an example link for your first agent.

Welcome message and starters

• Welcome message. Markdown (links, lists, bold), up to 4,000 characters, shown on the empty chat. These variables are filled in on the server and escaped: {{user.name}}, {{user.firstName}}, {{portal.name}}, {{agent.name}}.
• Pictures. Use Add a picture: the picture (PNG, JPEG, WebP or GIF up to 512 KB; at most 8 per portal) is stored with the portal and inserted at the cursor as ![](asset:image/{id}). Pictures from other addresses are not shown and the text is refused on save, so an image host can never see who opened the chat.
• Per agent. For each agent you can set a welcome message and starters. Starters are suggested first questions shown as buttons on the empty chat (up to 6 per agent; text up to 500 characters; an optional label up to 60; Send when clicked sends at once, otherwise the click only fills the box). Choose No starters or Set starters: the agent itself carries no welcome text or starters, a portal says all of that for itself.
• Which welcome wins. The portal's choice for the agent, then the portal's welcome text.
• May use the page's tools. While embedding is on, each agent also has a switch that lets it take the tools your page declared. It is off by default and belongs to this portal: the same agent can take page tools in one portal and not in another.
• A legacy portal keeps its plain welcome text exactly as before until you save this tab.

Compliance

The Compliance tab holds the terms people accept before using the portal and how the assistant is labelled.

Terms of use

Setting	Default	Detail
Ask people to accept terms	Off	When on, every chat route answers 403 terms_required until the person accepts.
Heading	Terms of use	Up to 120 characters.
Terms	—	Markdown, up to 20,000 characters. Required while terms are on.
Version	1	Not editable. It goes up by one automatically when the text changes after terms existed.
Ask again after	Never	Never, only when the terms change, or a number of days from 1 to 3,650.

How acceptance works:

• The first time a person opens the portal, the terms appear in a dialog before any of the chat is mounted. Accept and continue records the acceptance; Decline shows a "Terms not accepted" screen with Review the terms and sends nothing.
• Changing the text raises the version, so everyone is asked again. The same happens when an acceptance is older than the number of days you chose. If the terms changed while someone was reading, their acceptance is refused with 409 terms_changed and they are asked to reload the page to read the new text.
• Each acceptance is a row of its own: person, version, time, IP address and browser. Accepting again adds a row; the history of who accepted what stays. Accepting twice records once.
• The tab shows how many people accepted the current version and offers Export acceptances (CSV) (columns accepted_at, version, user_id, email, name, ip, user_agent).
• People using the embedded chat accept inside the embedded window.
• Acceptances from test sessions are kept apart and never counted.

AI label and legal links

Setting	Default	Detail
Label assistant messages	Off	A small label on every answer.
Label text	AI-generated (in the portal's language)	Up to 60 characters.
Privacy notice, Terms of service, Support, About the AI assistant	—	Shown as a link row under the input ("Privacy", "Terms", "Support", "How this AI works"). Full https addresses only, up to 500 characters; Support may also be a mailto: address. http:, javascript: and relative links are refused.

When the label is on or at least one link is set, they replace the free-text notice under the input; the notice you set under Appearance keeps working as the fallback.

Announcements

Announcements are banners at the top of the chat for maintenance notes or news.

Field	Default	Detail
Importance	Information	Information, Warning or Critical. Critical banners list first, then warnings, then information.
Text	—	Short Markdown, up to 500 characters (links and bold work).
Shows from / Shows until	Always	Optional start and end. The end must be after the start.
People can dismiss it	On	A dismissible banner has a close button and a person's dismissal is remembered in their browser. A banner that is not dismissible has no close button and stays until it ends.

Up to 20 announcements can be stored and at most 5 can be active at once; a schedule that would put more than five on screen at the same moment is refused on save. Each row shows whether it is Active now, Scheduled or Ended.

Editing an announcement's text or importance gives it a new identity, so people who closed the old one see the new one. Editing its dates or the dismiss setting does not.

Limits

The Limits tab sets how much one person can do in this portal. The platform sets the highest value of each limit; you can only lower it.

Limit	Default and platform maximum	Counts
Messages per minute	30	Messages, regenerations, edits, answers to approvals and questions, and "carry on" calls, per person.
File uploads per minute	20	Files stored per person.
Answers at the same time	5	Live event streams one person holds open (a reload that follows a running answer, a second tab), per node.
Conversations per person	200	Conversations one person keeps in this portal. Reaching it answers 429 TOO_MANY_CONVERSATIONS until they delete older ones.

Leave a field empty (Use the default) to use the platform value; a value above the maximum is refused (The value cannot be above 30), and so is anything below 1. The maxima are the platform defaults above unless an operator changes them with environment variables:

Variable	Default	Limit it sets
PORTAL_MAX_MESSAGES_PER_MINUTE	30	Messages per minute
PORTAL_MAX_UPLOADS_PER_MINUTE	20	File uploads per minute
PORTAL_MAX_STREAMS_PER_USER	5	Answers at the same time
PORTAL_MAX_CONVERSATIONS_PER_USER	200	Conversations per person

A change on the node that handles your save applies at once; other nodes pick it up within about 15 seconds. A person who goes over a rate limit sees "Too many requests. Wait a moment and try again." and the response carries a Retry-After header.

Some limits are fixed and not settings: opening conversations (20 per minute), starting event streams (30 per minute), exporting conversations (10 per minute), every other route (300 per minute), a message of at most 16,000 characters, and a request body of at most 64 KB (except file uploads, whose ceiling is FILE_UPLOAD_MAX_MB).

Test sessions and View as

Both tools answer "what would this look like for somebody else?" without leaving your own account.

Open as test

… → Open as test opens the portal for you in a new tab even when it is switched off or its access list does not include you.

Aspect	Behaviour
Who	Workspace owners and admins only. The role is checked again on every request, so a cookie of someone who is no longer an admin opens nothing.
How	A signed, HttpOnly cookie named cp_portal_test, bound to you, the workspace and that one portal, valid for 4 hours. It is not a session and is never accepted as one.
What you see	A banner "Test session. Nothing here is counted in the statistics." with Leave test, which removes the cookie and returns you to the portal page.
What is flagged	Conversations of a test session are marked as tests and left out of the statistics, the conversation counts and "last used". Terms acceptances and feedback given in a test are kept apart.
What still applies	The network restriction applies to test sessions too.
Audit	Each use is written to the audit log as the event portal.test_session (service portals), at most once a minute per person and portal.

View as

The Access tab's View as card shows what a person or a group would meet at this portal. Nothing runs and nobody is impersonated; it only asks the same policy engine the portal asks at run time.

1. Choose Person or Group and pick one.
2. Optionally enter From this address to test a network restriction, or tick Arriving through the embedded chat.
3. Press Show what they would see.

The answer says whether they can open the portal and, if not, why (for example "Only the access list opens a portal"), then lists each agent as Can use or Cannot use with the reasons. A group is checked as a plain member of it, with no other group. A disabled account and a switched-off portal are called out. At most the first 50 agents are decided.

Change history

The History tab records every change to the portal's settings: who, when, from where and what changed.

• One row per section. Changes are filed under General, Address, Status, Access, Agents, Appearance, Chat features, Compliance, Announcements, Limits, Embed and Signing secrets; a whole-portal event (Created, Imported, Deleted) is one row of its own. A duplicate is filed as Created.
• Each row shows When, Who, Section, From (the IP address), the reason (only older entries carry one: the tabs no longer ask for it), and Show the change with the before and after values; lists show what was added and removed.
• Filter by Section, press Load more to page, and Export (CSV) or Export (JSON). An export holds up to 10,000 rows, newest first, and tells you when it was cut.
• Never recorded: secrets (any value under a key that names one is replaced with [hidden]), image bytes (a logo is shown as its size), transcripts. Long texts are cut at 500 characters and long lists at 20 entries.
• The same event reaches the console audit log (service portals, events portal.config.created, .updated, .deleted, .imported and .duplicated) so an operator can ship it to a SIEM. When a portal is deleted its History goes with it; the deletion remains in the audit log.

Duplicate, export and import

Duplicate

Duplicate makes a copy with the same settings, a new name (default {name} (copy)) and an optional new address. The copy is disabled and has no secrets; set up its embed again. People's terms acceptances, conversations and statistics belong to the original and are not copied; the terms version starts again at 1.

Export settings

Export settings downloads portal-{address}-{date}.json. The file is built to move between workspaces: it names agents by key and project, groups by name and people by email, so a file from a staging workspace fits production. It contains the agents, access (including networks), theme, branding, browser-tab settings and images (while small), chat features, compliance, announcements, limits and the embed settings. It never contains signing secrets or tokens, terms acceptances, conversations, statistics or history.

Import settings

Import is available from the list (it creates a new, disabled portal) and from a portal's menu (it replaces that portal's settings). It always starts with a dry run:

1. Choose a file. The dialog tells you when it is not a portal export or was exported by a newer version.
2. For a new portal, set a name and an optional address. Press Check the file.
3. Read the report: how many agents, groups, people, announcements and pictures the file holds; the agents, groups and people that do not exist here (they are left out, never guessed); problems that would stop the import; and what the file carries that this portal keeps as it is.
4. Press Apply. It is disabled while the report has problems.

Import goes through the same checks as the form (publishable agents, valid ranges, ceilings) and writes a History row. A file can be up to 12 MB. When it replaces an existing portal, pictures the file does not carry are removed.

Importing never changes who may sign in through an embed

Into a new portal, embed settings arrive with embedding off and no shared secret. Over an existing portal, the allowed sites, signing, identity mapping, session rules, the embedding switch and the access rule for embedded people stay as the portal has them (the report lists the ones that would differ); only the look of the bubble and the declared page tools are applied.

Statistics and usage

The Statistics tab shows the portal's activity for the last 7, 30 or 90 days:

• Tiles for Conversations, Messages, Active users, Tokens and Cost (cost shows ≥ when some turns had no price).
• A Daily activity chart of conversations and messages (UTC days; every day is present, zero-filled).
• A By agent table with conversations, messages, tokens and cost per agent.

Tokens and Cost for the last seven days are on the Overview tab. The statistics API returns tokens and cost (totalTokens, costUsd) for every window, see the reference.

How the numbers are counted:

• A message counts on the day it was written, not the day its conversation started.
• Active users are people who sent at least one message; an assistant turn is not activity.
• Tokens and cost come from the usage stored with each assistant turn. When some turn reported tokens without a price, cost is a lower bound and shown as ≥. Title-writing calls are recorded as usage of the person but are not part of a portal's figures, which come from the turns of its conversations.
• Statistics read at most 5,000 conversations of the window; when more were active the figures are a lower bound (≥).
• Test sessions are excluded.

The Usage tab lists where the portal is used and what it depends on (the agents it offers).

Conversations

The Conversations tab lists what the people of the portal said to its agents, by date. It is read-only.

• Range and filters. A From and To date (the last seven days at first), the shortcuts Today, Last 7 days and Last 30 days, and an Agent filter. Dates are whole days in UTC.
• By day. Conversations are grouped under the day of their last message, newest first, 25 per page. A row shows the time, the person (name and e-mail), the agent, the title, the number of messages and the cost.
• Open one. Press a row to read the whole conversation in a side panel. Opening a conversation is written to the server log (who, which portal, which conversation). Test sessions are not listed.

Permission. The tab is decided by its own action in the access control center, portal.conversations_view, not by who may edit the portal. It sits at the Admin level, so by default only workspace owners and admins hold it. A deny rule can take it from an administrator. An ordinary member cannot be given it with an allow rule, because the action is above what their role reaches. A person without it sees an explanation instead of the list, and the API answers 403.

The API is GET /api/portals/{id}/conversations (from, to, agent, user, page, limit) and GET /api/portals/{id}/conversations/{conversationId}.

Embed

The Embed tab shows a portal inside your own application, as a floating chat bubble, an inline panel or an iframe, without a second login. Your application signs a short-lived token on its server; the portal verifies it and opens a session for that person. It is off by default and nothing about a portal that never used it changes.

Setting	Notes
Allow embedding	Master switch. With a shared secret it cannot be switched on before a secret exists.
Allowed sites	Exact https origins (no paths, no wildcards; http://localhost only on development and self-hosted installations). The portal answers frame-ancestors with this list, so no other site can frame it.
Token signing	HS256 with a shared secret that Console generates and shows once (up to two active so you can rotate), or RS256 / ES256 with a pasted public key or a JWKS address. The issuer, a token lifetime (at most 600 seconds, default 300) and whether the workspace must be part of the audience.
Who the token is	Match people by their token identity and/or a verified email address; what to do with a person nobody matches (refuse, create a member account, or create an external account); a map from token groups to console groups.
Session	5 minutes to 24 hours (default 60); optionally tied to the browser or the network range.
Chat bubble	Position, button text and icon, colour, open on load, size.
Tools in your page	Declare tools the agent may ask your page to run. Each has a JSON-Schema input, a wait of 1 to 600 seconds and an optional "ask the person first". The tools are offered only to the agents you switch on in the Chat features tab (May use the page's tools).
Access for embedded people	Must be on the access list (default) or Anyone your application has verified.
Try it	Enter a test person and press Start: a full-screen preview opens with a made-up site and the real chat on it. Tabs switch between Chat bubble (it opens and closes like the script's), Inside the page, Full screen and Phone; the colours can follow the system, or be light or dark; an events panel lists what the chat reported. Ready-made snippets (bubble, inline, iframe, React) sit next to it. An owner or admin account cannot sign in through an embed: use another e-mail address.
Sign everyone out	Ends every embedded session of the portal.

The network restriction and the access list apply to embedded people like anyone else. Signing secrets are never shown again and are never part of an export; creating, removing and rotating them is recorded in History under Signing secrets. The complete guide, with server examples for minting the token, the JavaScript API, events, page tools and Content-Security-Policy notes, is Embedding a portal.

Disable and delete

• Disable keeps everything and shows people who would be allowed in a "Portal unavailable" page. People who are not allowed in still see "No access": access is decided before status, so a refusal never reveals whether a portal is switched off.
• Delete asks for confirmation. The link stops working immediately; past conversations stay in the console history (listed read-only in Studio sessions). The portal's History is removed with it, the deletion stays in the audit log, and embed memberships the portal created for groups are released.

Security and privacy notes

• Fail closed. The policy engine decides on every request. If it cannot decide, the portal answers 503 and the person sees "Temporarily unavailable", never an allow and never a false "No access".
• Only the access list admits people. No role and no allow rule can open a portal the list does not name; deny rules can still narrow it. Network restrictions override everything.
• Cross-site protection. State-changing chat requests must be same-origin JSON; a file upload is accepted only with proof that it is same-origin. The portal page itself cannot be framed by other sites; the embed page is the only exception, and only for the sites you list.
• Conversations are ordinary agent conversations. They are tagged as portal conversations and are listed (read-only) in Studio sessions, so project members with read access to the agent can read portal transcripts. Tell the people you share a portal with.
• Feedback comments are readable by people who can edit the agent. Turn comments off if people might type personal data.
• Terms acceptances store each person's IP address and browser; mention it in your own privacy notice.
• Generated titles send the first question and answer (each cut to 700 characters) to the chosen model.
• Exports are audited with their format and are limited to the person's own conversations; tool calls are included only if you allow it.
• Welcome pictures can only come from the portal's own uploads, so image hosts never see who opened the chat. Legal links must be https.
• Errors. The chat server hides internal errors; only messages written for the person (and a reference code for refusals) are shown.
• History never records secrets. Signing secrets are shown once at creation and cannot be read back.

Next steps

• Using a portal — what your people see.
• Portal access boundaries — how the policy engine decides, with deny rules, networks, test sessions and View as in depth.
• Embedding a portal — show a portal inside your own application.
• Administration API and reference — automate setup and look up every setting and error code.
• Troubleshooting and FAQ — when somebody cannot get in.
• Build and publish an agent — the agent behind the portal.