diff --git a/docs-mintlify/admin/monitoring/chats-history.mdx b/docs-mintlify/admin/monitoring/chats-history.mdx
index 35cdab6c83cdd..ffe398de0587e 100644
--- a/docs-mintlify/admin/monitoring/chats-history.mdx
+++ b/docs-mintlify/admin/monitoring/chats-history.mdx
@@ -7,8 +7,9 @@ Admins, and users with the [**Access chat history**][ref-custom-roles] custom
 role permission, can view every user's chat conversations for a deployment.
 
 It's possible to search specific chats by the first message content or chat UUID.
-You can also filter the list by user type, creation date, and source
-(**Web**, **MCP**, **Slack**, **Scheduled**, or **API**).
+You can also filter the list by user type, creation date, and source — **Web**
+(including Analytics Chat and the Excel/Google Sheets add-in panes), **MCP**,
+**Slack**, **Scheduled**, or **API**.
 
 <video
   autoPlay
diff --git a/docs-mintlify/admin/monitoring/usage-analytics.mdx b/docs-mintlify/admin/monitoring/usage-analytics.mdx
index e03a728094347..70447c38e64c0 100644
--- a/docs-mintlify/admin/monitoring/usage-analytics.mdx
+++ b/docs-mintlify/admin/monitoring/usage-analytics.mdx
@@ -39,7 +39,7 @@ Each dashboard answers a different question about your account's usage.
 
 | Dashboard | Description |
 | --- | --- |
-| **Overview** | High-level health and adoption at a glance: requests, error rate, cache hit rate, response time, AI activity, and top tenants. |
+| **Overview** | High-level health and adoption at a glance: requests, error rate, cache hit rate, response time, and AI activity. |
 | **Query Activity & Performance** | Query volume by API type, latency percentiles, execution-stage breakdown, slowest queries, errors, and activity heatmap. |
 | **Users & Adoption** | Active users over time, new vs. returning users, engagement frequency, seat utilization, and dormant accounts. |
 | **AI & Token Tracking** | AI messages and conversations by surface, AI adoption, token consumption with estimated cost, and latency. |
@@ -51,18 +51,29 @@ Usage Analytics runs the full Cube application in
 the pre-built dashboards, you get the complete authoring experience: explore
 the usage data, create workbooks, and assemble your own dashboards from it.
 
-Your dashboards query the same three curated views that power the pre-built
-ones. Anything you build stays private unless you share it.
+Your dashboards can query every curated view below — including the five
+dashboard views, which no pre-built dashboard uses. Anything you build stays
+private unless you share it.
 
 | View | What it contains |
 | --- | --- |
-| **API Requests** | Every query hitting your deployments' data APIs, with timing, caching, errors, and the user, tenant, and deployment behind each request. |
+| **API Requests** | Every query hitting your deployments' data APIs, with timing, caching, and errors. `tenant_id` here is your own Cube account, not an embed tenant — row-level security pins every query to it, so this view can't be used to compare your embed tenants against each other. For per-request detail on one deployment, see [Query History](/admin/monitoring/query-history) instead. |
 | **AI Usage** | AI messages grouped into conversations and sessions, with context, token consumption, estimated cost, and latency. |
 | **Users & Adoption** | Users and their engagement: sign-ups, active users, activity frequency, seat utilization, and dormant accounts. |
-
-The API Requests view includes the security context behind each request, so
-embedded analytics customers can slice usage by tenant — for example, to find
-the heaviest tenants or compare per-tenant latency and cache efficiency.
+| **Dashboard Usage** | Every dashboard in your account — opens, viewers, surface, and when it was last touched — including ones nobody has opened yet. |
+| **Dashboard Engagement** | One row per view session: dwell time and whether the viewer did anything at all. |
+| **Dashboard Interactions** | In-dashboard actions: filter changes, refreshes, exports, drill-ins, chat opens. |
+| **Dashboard Authoring** | Publishes and deletions — who ships dashboard changes and who removes them. |
+| **Dashboard Inventory** | A daily snapshot of the dashboard estate, for trends over time. |
+
+If you embed Cube for multiple customers, Dashboard Usage carries
+`viewer_embed_tenant` — which of your embed customers' users did the looking.
+Dashboard Usage, Authoring, and Inventory all carry `embed_tenant_name` — which
+embed tenant the content itself belongs to. The two can disagree, since a viewer
+from one customer can open a dashboard that lives in another partition. Dashboard
+Engagement and Dashboard Interactions are collected client-side and are suppressed entirely
+for embedded Creator Mode, so they carry no embed-tenant breakdown and return
+nothing for embed-only traffic — that's suppression, not zero usage.
 
 ## Query programmatically
 
diff --git a/docs-mintlify/admin/users-and-permissions/custom-roles.mdx b/docs-mintlify/admin/users-and-permissions/custom-roles.mdx
index e74564733343d..4bb0e8cb90d3b 100644
--- a/docs-mintlify/admin/users-and-permissions/custom-roles.mdx
+++ b/docs-mintlify/admin/users-and-permissions/custom-roles.mdx
@@ -119,7 +119,7 @@ Either grant **Full access** (a shortcut that enables every current and future d
 | Data Model  | Edit data model                     | Edit the data model on any branch, including the main/deploy branch. Allows committing and merging to main, force-syncing main, and starting dev mode against main.       |
 | Data Model  | Edit data model on dev branches     | Edit the data model only on non-default branches. Blocks any write that targets the main/deploy branch (including merging to main).                                       |
 | Monitoring  | Access query history                | View deployment query history, performance, and traces.                                                                                                                   |
-| Monitoring  | Access chat history                 | View other users' Analytics Chat conversations for the deployment (**Admin → Chats History**).                                                                           |
+| Monitoring  | Access chat history                 | View other users' chat conversations for the deployment, including Analytics Chat and the Excel/Google Sheets add-in panes (**Admin → Chats History**).                  |
 | Data Export | Download data                       | Download query results as CSV from workbooks, Analytics Chat, and published dashboards. Granted by default to the built-in Viewer, Explorer, and Developer roles. See [Data download controls][ref-data-download-controls]. |
 
 When **Full access** is checked, the granular checkboxes appear checked and disabled — granting Full access today also covers any deployment-scoped permissions added in the future.
diff --git a/docs-mintlify/docs/explore-analyze/analytics-chat.mdx b/docs-mintlify/docs/explore-analyze/analytics-chat.mdx
index 8ef3eaaa2dfc2..53373adee46a5 100644
--- a/docs-mintlify/docs/explore-analyze/analytics-chat.mdx
+++ b/docs-mintlify/docs/explore-analyze/analytics-chat.mdx
@@ -17,6 +17,7 @@ The AI agent interprets your questions, generates queries against your semantic
 - **Semantic model integration** – All queries run against your semantic model with proper access control and security, honoring the active [security context](/docs/explore-analyze/workbooks/querying-data#applying-a-security-context)—including an override applied by a developer or admin
 - **Queued messages** – Send follow-up messages while the agent is still processing
 - **Save your results** – Ask the agent to save a result as a [report](/docs/explore-analyze/workbooks) inside a workbook, or as a standalone [exploration](/docs/explore-analyze/explore#saving-explorations) when you don't want to create a workbook
+- **Organize saved work** – Ask the agent to save an exploration into a specific [folder](/docs/organize-content/folders), or to list, create, rename, move, or delete folders in your workspace — folder actions run immediately, and deletion [destroys less than the Workspace page but checks less too](/docs/organize-content/folders#deleting-folders)
 - **Link saved artifacts** – The agent can link an existing exploration, workbook, or dashboard to the conversation, on request or automatically when it creates or edits one, so you can reopen it from the thread later
 
 ## Discover available fields
diff --git a/docs-mintlify/docs/explore-analyze/dashboards/index.mdx b/docs-mintlify/docs/explore-analyze/dashboards/index.mdx
index 4d77991de4305..52dc36fb6505b 100644
--- a/docs-mintlify/docs/explore-analyze/dashboards/index.mdx
+++ b/docs-mintlify/docs/explore-analyze/dashboards/index.mdx
@@ -130,7 +130,8 @@ that owns it; exporting a single chart requires the **Download data**
 permission. Both are hidden entirely when an admin turns off the account-wide
 [data download controls][ref-data-download-controls]. The same screenshot
 mechanism powers PNG/PDF attachments on [notifications][ref-notifications] sent
-after a [scheduled refresh][ref-scheduled-refreshes].
+after a [scheduled refresh][ref-scheduled-refreshes], and is also available
+programmatically — see the [Control Plane API][ref-control-plane-api].
 
 [ref-workbooks]: /docs/explore-analyze/workbooks
 [ref-widgets]: /docs/explore-analyze/dashboards/widgets
@@ -139,3 +140,4 @@ after a [scheduled refresh][ref-scheduled-refreshes].
 [ref-notifications]: /docs/explore-analyze/notifications
 [ref-scheduled-refreshes]: /docs/explore-analyze/scheduled-refreshes
 [ref-data-download-controls]: /admin/users-and-permissions/roles-and-permissions#restricting-data-downloads
+[ref-control-plane-api]: /reference/control-plane-api#apiv1deploymentsdeployment_iddashboard-exports
diff --git a/docs-mintlify/docs/integrations/google-sheets.mdx b/docs-mintlify/docs/integrations/google-sheets.mdx
index 77449f367069d..660183b95699f 100644
--- a/docs-mintlify/docs/integrations/google-sheets.mdx
+++ b/docs-mintlify/docs/integrations/google-sheets.mdx
@@ -181,6 +181,30 @@ change.
 
 {/* TODO: screenshot — a pivoted exploration with the Total row on the sheet */}
 
+### Row totals
+
+The **Row totals** switch, next to **Column totals** on the **Display** tab,
+appends a bold **Total** column at the right of the written range, totaling
+each row across the pivot columns. It needs a measure in the query and a
+dimension on **Columns** to pivot across — it's disabled, with a tooltip
+explaining which is missing, until both are set. With measures on **Columns**,
+each measure gets its own total column; with measures on **Rows**, a single
+total column covers them all, since each row already holds one measure.
+
+Like column totals, each total comes from a separate query grouped by the
+opposite zone, so the same rules apply: correct for non-additive measures,
+window-function [calculations][ref-calculated-fields] excluded, measure
+filters dropped and dimension filters kept, and totals taken over the query's
+full result rather than the rows on the sheet. With both switches on,
+the cell where they meet holds a grand total across the whole result, from a
+third query with neither zone kept.
+
+Row totals are saved with the exploration and survive **Refresh** too; with
+auto-run off, toggling the switch waits for **Run** like any other display
+change.
+
+{/* TODO: screenshot — a pivoted exploration with the Total column on the sheet */}
+
 When your exploration is ready, click **Save** to add it to your workspace. You
 can then [work with the exploration](#work-with-explorations) from the add-on.
 To discard an unsaved exploration instead, choose **Delete exploration** from
@@ -264,17 +288,28 @@ The chat pane is currently in preview, and the tools it can call may still chang
 With chat enabled, the add-on's sidebar gains a pane that can act on the
 spreadsheet, not just answer questions about it. Ask it to run a query and
 place the results, or refresh or clear a placed exploration. It can also
-create, rename, or delete a sheet.
+create, rename, or delete a sheet, and organize your saved explorations into
+[folders][ref-folders] — list, create, rename, move, or delete one on
+request. Deleting one this way [destroys less than the Workspace page but checks
+less too][ref-deleting-folders].
+
+Drag a saved exploration or an unsaved draft from the spreadsheet's home onto
+the chat composer to attach it as context for your next question.
 
-Before any destructive or ambiguous action — writing over an occupied area,
-clearing a placement, renaming or deleting a sheet — the pane asks you to
-confirm first. A query the agent places lands as an **unsaved** exploration;
-save it yourself if you want to keep it.
+Before any destructive or ambiguous action on the sheet — writing over an
+occupied area, clearing a placement, renaming or deleting a sheet — the pane
+asks you to confirm first. A query the agent places lands as an **unsaved**
+exploration; save it yourself if you want to keep it. Folder actions are the
+exception: creating, renaming, moving, or deleting one runs immediately,
+without a confirmation step.
 
 Answers are tables, not charts — the chat pane doesn't render
-visualizations. Chat history is stored locally per spreadsheet, on the
-device where you had the conversation — it isn't available if you open the
-file elsewhere.
+visualizations. Past conversations are listed under **Chat History** in the
+pane — every conversation you've had in the add-on on this deployment, not
+just the current spreadsheet's — and sync with your Cube account, so they're
+available from any device. Like other conversations, they're readable by
+admins and anyone with the **Access chat history** permission under
+[Chats History](/admin/monitoring/chats-history).
 
 {/* TODO: screenshot — the chat pane open in the add-on sidebar */}
 
@@ -288,3 +323,5 @@ file elsewhere.
 [ref-sql-api-enabled]: /reference/core-data-apis/sql-api#cube-cloud
 [ref-explorations]: /docs/explore-analyze/explore#saving-explorations
 [ref-calculated-fields]: /docs/explore-analyze/workbooks/calculated-fields
+[ref-folders]: /docs/organize-content/folders
+[ref-deleting-folders]: /docs/organize-content/folders#deleting-folders
diff --git a/docs-mintlify/docs/integrations/mcp-server.mdx b/docs-mintlify/docs/integrations/mcp-server.mdx
index 5c178dd70af75..544a87e89f7be 100644
--- a/docs-mintlify/docs/integrations/mcp-server.mdx
+++ b/docs-mintlify/docs/integrations/mcp-server.mdx
@@ -233,32 +233,51 @@ queried.
 
 ## Available actions
 
-The MCP server exposes 23 tools, grouped below.
+The MCP server exposes 30 tools, grouped below.
 
 Every tool runs as the authenticated user. Queries respect the same
 [permissions][ref-roles] as the rest of Cube, including row-level security — MCP is a new
-way to reach your data, not a new access surface.
+way to reach your data, not a new access surface — with one exception, reachable two
+ways: deleting a [workspace folder][ref-folders] skips the content-permission check the
+Workspace page applies, whether it's [`manageFolders`](#dashboard-authoring) or the
+agent behind [`chat`](#deployments-and-chat) doing the deleting.
 
 ### Read and write tools
 
-Each tool is annotated as read-only or destructive. MCP clients that honor these
+Each tool is annotated as read-only, write, or destructive. MCP clients that honor these
 annotations — including Claude — run read-only tools automatically and **always ask for
-confirmation** before any of the six destructive ones: `updateReport`, `deleteReport`,
-`updateDashboard`, `publishDashboard`, `writeDataModelFile`, and `deleteDataModelFile`.
-Nothing that changes a workbook report, an exploration, a dashboard, or your data model
-happens without an explicit approval.
+confirmation** before any of the nine destructive ones: `updateReport`, `deleteReport`,
+`manageFolders`, `updateDashboard`, `publishDashboard`, `writeDataModelFile`,
+`deleteDataModelFile`, `mergeToDefaultBranch`, and `discardDataModelChanges`. A tool
+annotated write, not destructive, may run without a prompt — including
+`commitDataModelChanges`, which can publish straight to production in one case; see [How
+model edits stay safe](#how-model-edits-stay-safe). A tool annotated read-only can still
+cause a write once it runs — `chat` is that case; see [Deployments and
+chat](#deployments-and-chat).
 
 ### Deployments and chat
 
-| Tool | Description |
-| --- | --- |
-| `listDeployments` | Lists the deployments and agents you can reach over MCP. |
-| `chat` | Asks a question of a Cube agent, optionally targeting a specific deployment and agent. Pass `branchName` to have the agent answer from a dev branch's model instead of the deployed one. |
-| `loadQueryResults` | Paginates through the results of a previous query. |
+| Tool | Description | Access |
+| --- | --- | --- |
+| `listDeployments` | Lists the deployments and agents you can reach over MCP. | Read-only |
+| `chat` | Asks a question of a Cube agent, optionally targeting a specific deployment and agent. Pass `branchName` to have the agent answer from a dev branch's model instead of the deployed one. | Read-only — see warning below |
+| `loadQueryResults` | Paginates through the results of a previous query. | Read-only |
 
 See [Select a deployment and agent](#select-a-deployment-and-agent) for how these three
 work together.
 
+<Warning>
+
+`chat`'s **Read-only** annotation covers only the MCP call itself, not what the agent
+does in response. It's the same agent Analytics Chat uses, with the same write-capable
+tools — creating reports, organizing workspace folders — when the caller's access allows
+it, and the agent's own folder actions run with no confirmation step — unlike
+`manageFolders` below, which a client prompts for. A client that runs `chat`
+automatically because the annotation says read-only can still cause an unconfirmed write
+through the agent's own reply.
+
+</Warning>
+
 A chat conversation is pinned to whichever branch answered its first message — later
 messages in the same conversation stay on that branch, and `loadQueryResults` pages using
 it. Passing a different `branchName` while resuming an existing `chatId` fails rather than
@@ -293,10 +312,11 @@ programmatically. Creating and editing workbooks requires the Explorer role or h
 | --- | --- | --- |
 | `readWorkbook` | Reads a workbook — its name and its current dashboard draft and published configs. | Read-only |
 | `createWorkbook` | Creates a new empty workbook, the container that holds reports and a dashboard. | Write |
-| `createReport` | Saves a query plus its visualization. Pass `workbookId` to create a report inside a workbook and get the `reportId` a chart widget references; omit `workbookId` to save a standalone [exploration](/docs/explore-analyze/explore#saving-explorations) instead. | Write |
+| `createReport` | Saves a query plus its visualization. Pass `workbookId` to create a report inside a workbook and get the `reportId` a chart widget references; omit `workbookId` to save a standalone [exploration](/docs/explore-analyze/explore#saving-explorations) instead. Pass `folderId` to file a standalone exploration in a [workspace folder][ref-folders]. | Write |
 | `readReport` | Reads one workbook report or standalone exploration by id — its title, SQL, chart spec, placement, and a shareable URL. | Read-only |
-| `updateReport` | Edits an existing workbook report or exploration in place, keeping its `reportId`. Send only the fields you want to change. | Destructive — prompts |
+| `updateReport` | Edits an existing workbook report or exploration in place, keeping its `reportId`. Send only the fields you want to change — including `folderId` to move a standalone exploration into a [workspace folder][ref-folders]. | Destructive — prompts |
 | `deleteReport` | Deletes a workbook report or exploration. | Destructive — prompts |
+| `manageFolders` | Lists, creates, renames, moves, or deletes the [workspace folders][ref-folders] that standalone explorations, workbooks, and dashboards are filed in. | Destructive — prompts |
 | `updateDashboard` | Saves the dashboard layout to the workbook **draft**. Replaces the full widget set and does not go live. | Destructive — prompts |
 | `publishDashboard` | Publishes the current draft to make it live. Idempotent — republishing an unchanged draft is a no-op. | Destructive — prompts |
 
@@ -304,6 +324,12 @@ Drafts are the safety net here: `updateDashboard` only ever writes to the draft,
 published dashboard keeps serving its previous version until you approve
 `publishDashboard`. See [Build a dashboard](#build-a-dashboard) for the full sequence.
 
+Call `manageFolders` with `action: "list"` first to get a folder's numeric id — that id,
+not its name, is what `folderId` takes on `createReport` and `updateReport` to place a
+standalone exploration inside it. The annotation covers the whole tool, so a client
+prompts for `list` as it would for `delete`. Its delete [destroys less than the
+Workspace page but checks less too][ref-deleting-folders].
+
 **To change an existing report, use `updateReport` — never recreate it.** A dashboard's
 chart widget points at a specific `reportId`, so replacing a report with a new one orphans
 every widget referencing it. The same caution applies to moving a report between workbooks:
@@ -341,30 +367,73 @@ variable is set without ever seeing what it is set to.
 
 </Note>
 
-#### How model edits stay safe
+### How model edits stay safe
 
-Letting an AI client edit your semantic model is safe because of four constraints built
-into the MCP server:
+Model editing over MCP is constrained by several mechanisms — most enforced by the MCP
+server, one by clients that honor tool annotations, and one that is yours to apply —
+with one gap noted below:
 
-- **Edits never touch production.** Every write goes to a personal dev branch named
-  `dev-<user>-<hash>`. The write tools reject any branch that isn't a dev branch, so
-  the deploy branch is never writable over MCP.
+- **File writes never touch production.** Every write goes to a personal dev branch named
+  `dev-<user>-<hash>`. `writeDataModelFile` and `deleteDataModelFile` reject any branch
+  that isn't a dev branch, so no file edit can land on the deploy branch directly.
 - **`startDataModelEdit` is the only entry point.** It returns the dev `branchName`, and
   `writeDataModelFile` and `deleteDataModelFile` require it. There is no way to write
   without going through it first.
-- **Promotion is manual and human.** To publish model changes you commit the dev branch
-  from the Cube UI, as described in [Development mode][ref-dev-mode]. The MCP server
-  deliberately exposes no commit tool — an AI client can prepare changes, but only a
-  person can ship them.
-- **Registration is permission-gated.** Every tool in the two sections above — the six
-  model-editing tools, `getBranchDiff`, `getDeploymentEnv`, and both pre-aggregation
-  tools — is offered only to users whose role allows editing the semantic model. A Viewer
-  never sees them at all.
-- **Verification happens on the branch, before a merge, not after.** Pass the dev
-  `branchName` to `runQuery` to check that an edit returns the right data — `valid: true`
-  from `writeDataModelFile` only means the model compiles, not that it's correct.
-
-Review pending work with `getDataModelChanges` before you commit.
+- **Merging a branch to production prompts for confirmation.** `mergeToDefaultBranch` — the tool
+  that publishes an already-committed branch — is marked destructive, so a client always
+  prompts for confirmation. See [Committing and publishing
+  changes](#committing-and-publishing-changes).
+- **Registration is permission-gated.** Every tool in Data model editing, Committing and
+  publishing changes, and Pre-aggregations — the six model-editing tools, `getBranchDiff`,
+  `getDeploymentEnv`, the six commit and branch tools, and both pre-aggregation tools — is
+  offered only to users whose role allows editing the semantic model. A Viewer never sees
+  any of them.
+- **Deploy-branch writes are permission-checked at call time.** A role scoped to **Edit data
+  model on dev branches** still sees every tool listed above registered, but `mergeToDefaultBranch`
+  and `commitDataModelChanges` with `confirmPublishToDefaultBranch` fail for that role, the
+  same as any other write targeting the deploy branch.
+- **Verify on the branch, before a merge, not after.** Pass the dev `branchName` to
+  `runQuery` to check that an edit returns the right data — `valid: true` from
+  `writeDataModelFile` only means the model compiles, not that it's correct.
+
+<Warning>
+
+`commitDataModelChanges` is a second route to production: a dev branch created from the
+deploy branch commits straight onto it, live, when the call sets
+`confirmPublishToDefaultBranch`. That tool is **not** annotated destructive, so a client
+isn't guaranteed to prompt first. For a role that holds full **Edit data model**, the
+tool's own description is the only thing standing in the way — it tells the agent to set
+the flag only on your explicit say-so, never to retry a refusal on its own.
+
+</Warning>
+
+### Committing and publishing changes
+
+Editing the model with the tools above only ever writes to a personal dev branch's
+working copy — reachable on that branch's endpoints, and in the Cube UI once you've
+switched to it, but invisible to everyone else until it's committed. These tools commit
+that work, publish it, or throw it away. They're registered under the same
+semantic-model permission as the data model tools above, and a client can call them
+without ever using the Cube UI.
+
+| Tool | Description | Access |
+| --- | --- | --- |
+| `getBranchState` | Reports the branch this session works on, the branch you're looking at in the Cube UI, the deploy branch, and whether the session's branch has uncommitted edits. | Read-only |
+| `commitDataModelChanges` | Commits the dev branch's edits onto the branch it was created from — including the deploy branch, live, when the call sets `confirmPublishToDefaultBranch`. | Write — see [How model edits stay safe](#how-model-edits-stay-safe) |
+| `commitToNewBranch` | Commits the dev branch's edits to a new branch instead, optionally opening a pull request. | Write |
+| `mergeToDefaultBranch` | Merges a committed branch into the deploy branch, making it live for everyone. | Destructive — prompts |
+| `discardDataModelChanges` | Resets the dev branch to its parent (or to a given commit hash), throwing away pending edits. | Destructive — prompts |
+| `switchUserBranch` | Switches your own Cube UI over to a branch, the same action as its branch switcher, so you can see and test what was committed. | Write |
+
+These mirror the "Commit & Sync", "Merge" / "Create a Pull Request", and branch-switching
+actions described in [Development mode][ref-dev-mode] — a client can now drive that same
+flow instead of asking you to click through it. One difference: the UI's Merge button
+targets the branch's parent, whichever branch that is, while `mergeToDefaultBranch`
+always targets the deploy branch.
+
+Call `getBranchState` before editing, to see whether the MCP session's branch and the
+branch your Cube UI shows are the same, and again after committing, to see whether you
+still need `switchUserBranch` to see the result.
 
 ### Pre-aggregations
 
@@ -408,8 +477,9 @@ members, then run your own SQL with `runQuery`.
 ### Build a dashboard
 
 Four of the dashboard tools build a new dashboard, and they are designed to be used in
-order. The rest — `readWorkbook`, `readReport`, `updateReport`, `deleteReport` — are for
-inspecting and changing one that already exists.
+order. `readWorkbook`, `readReport`, `updateReport`, and `deleteReport` inspect and
+change one that already exists, and `manageFolders` organizes the workspace folders
+those workbooks and dashboards live in.
 
 <Steps>
   <Step title="Create the workbook">
@@ -445,13 +515,26 @@ with `writeDataModelFile` or `deleteDataModelFile`, passing that `branchName`. E
 recompiles the model and reports validation errors, so you can iterate until it compiles.
 Before committing, verify the change returns the right data: call `runQuery` with the same
 `branchName` and check the numbers, since a compiling model can still return wrong results.
-Review the result with `getDataModelChanges`, then commit the branch from the Cube UI to
-publish it.
+Review the result with `getDataModelChanges`, then see [Ship a model
+edit](#ship-a-model-edit) to land the change and make it live.
 
 To review a branch you didn't author — a colleague's feature branch, say — call
 `getBranchDiff` with its name instead. It compares against the deploy branch and returns
 the full changed-file list even when the patch itself is trimmed.
 
+### Ship a model edit
+
+Once `writeDataModelFile` edits compile and `runQuery` confirms they return the right
+data, call `commitDataModelChanges` to land them on the branch the dev branch forked
+from — read [How model edits stay safe](#how-model-edits-stay-safe) first if that
+branch is the deploy branch. Use `commitToNewBranch` instead to put them on a new
+branch, optionally with a pull request.
+Either way, use `switchUserBranch` to point your own Cube UI at the result so you can
+see it. `mergeToDefaultBranch` is the publish step: it makes the branch live for
+everyone, so call it only when you want the change in production — no tool reverts it
+afterwards. If an edit isn't working out, `discardDataModelChanges` throws it away
+instead of committing it; it resets the dev branch only, so it is not an undo for a merge.
+
 ### Verify a pre-aggregation
 
 After adding or changing a pre-aggregation, call `getPreAggregationStatus` to see whether
@@ -475,3 +558,5 @@ and friends) are set.
 [ref-workbooks]: /docs/explore-analyze/workbooks
 [ref-dashboards]: /docs/explore-analyze/dashboards
 [ref-dev-mode]: /docs/data-modeling/dev-mode
+[ref-folders]: /docs/organize-content/folders
+[ref-deleting-folders]: /docs/organize-content/folders#deleting-folders
diff --git a/docs-mintlify/docs/integrations/microsoft-excel.mdx b/docs-mintlify/docs/integrations/microsoft-excel.mdx
index 002df503e42cc..1cd5a200595c4 100644
--- a/docs-mintlify/docs/integrations/microsoft-excel.mdx
+++ b/docs-mintlify/docs/integrations/microsoft-excel.mdx
@@ -170,6 +170,30 @@ change.
 
 {/* TODO: screenshot — a pivoted exploration with the Total row on the sheet */}
 
+### Row totals
+
+The **Row totals** switch, next to **Column totals** on the **Display** tab,
+appends a bold **Total** column at the right of the written range, totaling
+each row across the pivot columns. It needs a measure in the query and a
+dimension on **Columns** to pivot across — it's disabled, with a tooltip
+explaining which is missing, until both are set. With measures on **Columns**,
+each measure gets its own total column; with measures on **Rows**, a single
+total column covers them all, since each row already holds one measure.
+
+Like column totals, each total comes from a separate query grouped by the
+opposite zone, so the same rules apply: correct for non-additive measures,
+window-function [calculations][ref-calculated-fields] excluded, measure
+filters dropped and dimension filters kept, and totals taken over the query's
+full result rather than the rows on the sheet. With both switches on,
+the cell where they meet holds a grand total across the whole result, from a
+third query with neither zone kept.
+
+Row totals are saved with the exploration and survive **Refresh** too; with
+auto-run off, toggling the switch waits for **Run** like any other display
+change.
+
+{/* TODO: screenshot — a pivoted exploration with the Total column on the sheet */}
+
 When your exploration is ready, click **Save** to add it to your workspace. You
 can then [work with the exploration](#work-with-explorations) from the add-in.
 To discard an unsaved exploration instead, choose **Delete exploration** from
@@ -253,17 +277,28 @@ The chat pane is currently in preview, and the tools it can call may still chang
 With chat enabled, the add-in's sidebar gains a pane that can act on the
 workbook, not just answer questions about it. Ask it to run a query and
 place the results, or refresh or clear a placed exploration. It can also
-create, rename, or delete a sheet.
+create, rename, or delete a sheet, and organize your saved explorations into
+[folders][ref-folders] — list, create, rename, move, or delete one on
+request. Deleting one this way [destroys less than the Workspace page but checks
+less too][ref-deleting-folders].
+
+Drag a saved exploration or an unsaved draft from the workbook's home onto
+the chat composer to attach it as context for your next question.
 
-Before any destructive or ambiguous action — writing over an occupied area,
-clearing a placement, renaming or deleting a sheet — the pane asks you to
-confirm first. A query the agent places lands as an **unsaved** exploration;
-save it yourself if you want to keep it.
+Before any destructive or ambiguous action on the sheet — writing over an
+occupied area, clearing a placement, renaming or deleting a sheet — the pane
+asks you to confirm first. A query the agent places lands as an **unsaved**
+exploration; save it yourself if you want to keep it. Folder actions are the
+exception: creating, renaming, moving, or deleting one runs immediately,
+without a confirmation step.
 
 Answers are tables, not charts — the chat pane doesn't render
-visualizations. Chat history is stored locally per workbook, on the device
-where you had the conversation — it isn't available if you open the file
-elsewhere.
+visualizations. Past conversations are listed under **Chat History** in the
+pane — every conversation you've had in the add-in on this deployment, not
+just the current workbook's — and sync with your Cube account, so they're
+available from any device. Like other conversations, they're readable by
+admins and anyone with the **Access chat history** permission under
+[Chats History](/admin/monitoring/chats-history).
 
 {/* TODO: screenshot — the chat pane open in the add-in sidebar */}
 
@@ -279,3 +314,5 @@ elsewhere.
 [link-ms-appsource]: https://appsource.microsoft.com/en-us/product/office/WA200008486
 [ref-explorations]: /docs/explore-analyze/explore#saving-explorations
 [ref-calculated-fields]: /docs/explore-analyze/workbooks/calculated-fields
+[ref-folders]: /docs/organize-content/folders
+[ref-deleting-folders]: /docs/organize-content/folders#deleting-folders
diff --git a/docs-mintlify/docs/organize-content/folders.mdx b/docs-mintlify/docs/organize-content/folders.mdx
index ee3226c0e3ff7..b913465f21613 100644
--- a/docs-mintlify/docs/organize-content/folders.mdx
+++ b/docs-mintlify/docs/organize-content/folders.mdx
@@ -134,6 +134,23 @@ dashboards, and explorations — along with it; this cannot be undone.
 If anything inside the folder has its own permissions and you don't have Full
 access there too, deletion is blocked entirely and nothing is deleted.
 
+Asking [Analytics Chat](/docs/explore-analyze/analytics-chat), the Excel or Google
+Sheets chat pane, an MCP client, or the [REST API](/api-reference/folders/delete-a-folder)
+to delete a folder is narrower in what it destroys than deleting it here: it only
+removes the folder itself — contents move to the workspace root instead of being
+deleted — and it refuses a folder that still has subfolders, rather than deleting
+the whole subtree.
+
+<Warning>
+
+These paths are **wider** in who can do it. They only check that you have
+**Full access** (**manage** access, for the REST API) to the folder itself —
+they never apply the content-permission check above. Full access to a folder
+alone is enough to scatter its contents to the workspace root, even contents
+you don't otherwise have access to.
+
+</Warning>
+
 ## Folder permissions
 
 Folder access is controlled through three permission levels:
diff --git a/docs-mintlify/embedding/iframe/creator-mode.mdx b/docs-mintlify/embedding/iframe/creator-mode.mdx
index 4fd1dc169d9bc..9d5b8e97cb6ef 100644
--- a/docs-mintlify/embedding/iframe/creator-mode.mdx
+++ b/docs-mintlify/embedding/iframe/creator-mode.mdx
@@ -33,6 +33,10 @@ back out for a given customer or a given placement:
   whether it shows at all, and whether embed users may see Semantic SQL and
   Generated SQL.
 
+Export works the other way: it's hidden by default, and the iframe URL parameter
+`allowExport=true` grants it, adding **Download as CSV** in the report builder
+alongside the dashboard download actions it already controls.
+
 [Show and hide features](/embedding/iframe/feature-visibility) documents all of
 them, and the rule for which layer to use.
 
diff --git a/docs-mintlify/embedding/iframe/dashboards.mdx b/docs-mintlify/embedding/iframe/dashboards.mdx
index 72f197b55e610..6bc0dfbdb2f5e 100644
--- a/docs-mintlify/embedding/iframe/dashboards.mdx
+++ b/docs-mintlify/embedding/iframe/dashboards.mdx
@@ -120,13 +120,14 @@ as PNG**, and **Download as PDF** actions, and a dashboard-level ⋮ appears —
 docked in the header in [Creator Mode](/embedding/iframe/creator-mode),
 floating over the dashboard in the published-dashboard embed — with **Download
 as PNG** and **Download as PDF** for the whole dashboard. `allowExport` is the
-single switch for all of these — there is no way to allow one format while
-blocking another, or to allow chart-level export without dashboard-level
-export. Only the exact literal string `true` opts in: `allowExport=1`,
+single switch that grants all of these — there is no way to allow one format
+while blocking another. It also grants **Download as CSV** in the Creator
+Mode report builder; see [Show and hide features](/embedding/iframe/feature-visibility).
+Only the exact literal string `true` opts in: `allowExport=1`,
 `allowExport=TRUE`, a bare `?allowExport`, and omitting the parameter (the
 default) all leave every download action hidden.
 
-The CSV is generated client-side from the data already loaded into the
+A widget's CSV is generated client-side from the data already loaded into the
 widget, so no additional query is issued. Inside an embed, `allowExport` —
 not the viewer's own Cube role — is the authority on whether the download
 actions appear. The account-wide **Allow data downloads** switch outranks it —
diff --git a/docs-mintlify/embedding/iframe/events.mdx b/docs-mintlify/embedding/iframe/events.mdx
index edf73c088bb32..fc925a05bf5fa 100644
--- a/docs-mintlify/embedding/iframe/events.mdx
+++ b/docs-mintlify/embedding/iframe/events.mdx
@@ -483,9 +483,9 @@ for it and retry.
 ## Keeping a signed session alive
 
 A signed embed's token is usable for about 23 hours (see [Session
-lifecycle](/embedding/iframe/auth/signed#how-it-works)) and can't refresh
-itself — left alone, a tab open that long drops to a "Session expired"
-message. Renew it in place instead.
+lifecycle](/embedding/iframe/auth/signed#how-it-works)), unless revoked
+sooner, and can't refresh itself — left alone, a tab open that long drops to
+a "Session expired" message. Renew it in place instead.
 
 If you're using `@cube-dev/embed-sdk`, call `autoRenewSession` on the
 connection instead of hand-rolling the listener below — it drives renewal
@@ -538,6 +538,15 @@ window.addEventListener("message", (event) => {
 });
 ```
 
+### Ending a session on logout
+
+Letting the token expire isn't the same as logging the viewer out — for that,
+[revoke the embed session](/reference/embed-apis/generate-session#revoke-a-session) from
+your own logout handler. Every renewal mints a new session id, so track each
+one you've minted for that viewer and revoke all of them; an earlier one may
+still be a live, unexpired token. Revoking doesn't tear down a running
+iframe by itself — remove it as you normally would on logout.
+
 ## Surfaces
 
 Events come from one of three customer-facing surfaces, reported in the envelope's
diff --git a/docs-mintlify/embedding/iframe/feature-visibility.mdx b/docs-mintlify/embedding/iframe/feature-visibility.mdx
index 04da2c51811f6..352f604adfe25 100644
--- a/docs-mintlify/embedding/iframe/feature-visibility.mdx
+++ b/docs-mintlify/embedding/iframe/feature-visibility.mdx
@@ -133,13 +133,13 @@ they are ignored outside `/embed/*`.
 
 | Parameter | Effect | Surface |
 | --- | --- | --- |
-| `allowExport=true` | Offers per-widget **Download as CSV / PNG / PDF** on chart widgets. The single switch for all three formats. | Dashboards |
-| `showDashboardExportMenu=false` | Hides the whole-dashboard download menu (in the Creator Mode dashboard header; floating over a published-dashboard embed). A hide switch, not the grant — `allowExport=true` is still what hands out export at all. | Dashboards |
-| `showDashboardHeader=false` | Hides the entire dashboard header bar. | Dashboards |
-| `showDashboardBackButton=false` | Hides the dashboard header's back button. | Dashboards |
-| `showDashboardTitle=false` | Hides the dashboard title. | Dashboards |
-| `showDashboardEditButton=false` | Hides the **Edit** action. Can only hide it — it never shows one to a viewer without edit permission. | Dashboards |
-| `showDashboardDuplicateButton=false` | Hides the **Duplicate** action. | Dashboards |
+| `allowExport=true` | The grant for export: per chart widget **Download as CSV / PNG / PDF**, the whole-dashboard download menu, and **Download as CSV** in the Creator Mode report builder, where a workbook's queries are authored before publishing. | Dashboards, Creator Mode |
+| `showDashboardExportMenu=false` | Hides the whole-dashboard download menu (in the Creator Mode dashboard header; floating over a published-dashboard embed). A hide switch, not the grant — `allowExport=true` is still what hands out export at all. | Dashboards, Creator Mode |
+| `showDashboardHeader=false` | Hides the entire dashboard header bar. | Dashboards, Creator Mode |
+| `showDashboardBackButton=false` | Hides the dashboard header's back button. | Dashboards, Creator Mode |
+| `showDashboardTitle=false` | Hides the dashboard title. | Dashboards, Creator Mode |
+| `showDashboardEditButton=false` | Hides the **Edit** action. Can only hide it — it never shows one to a viewer without edit permission. | Dashboards, Creator Mode |
+| `showDashboardDuplicateButton=false` | Hides the **Duplicate** action. | Dashboards, Creator Mode |
 | `showWorkbookBackButton=false` | Hides the back button in the Creator Mode **workbook** header. The rest of that header is the authoring flow (name, tabs, Publish, Share), so there is no master switch for it. The workbook actions menu keeps its **View all** item, which reaches the same place. | Creator Mode |
 | `locale=es-MX` | Sets the embed's UI language, overriding `settings.locale`. See [Localization](/embedding/iframe/localization). | All |
 | `timezone=America/New_York` | Sets the time zone agent queries run in, overriding `settings.timezone`. See [Time zones](/embedding/iframe/time-zones). | All |
@@ -149,7 +149,10 @@ in its own chrome otherwise ends up with two of everything — most visibly two
 back buttons that navigate to different places. Each control is its own switch
 because which of them duplicate yours is your decision; `showDashboardHeader=false`
 is the shortcut for all of them, and hiding the last remaining control collapses
-the bar for you.
+the bar for you. These switches govern the same header in Creator Mode's dashboard
+view too, which renders the identical back button, title, Edit, Duplicate, and
+download-menu controls — a different header from the workbook-editing one
+`showWorkbookBackButton` controls.
 
 ### How values are parsed {#parsing}
 
@@ -231,10 +234,12 @@ shape the product your users see; they are not a replacement for permissions.
 - **URL parameters are visible to the viewer.** They are chrome and layout
   decisions, made per placement. Anything a viewer must not be able to turn back
   on belongs in the session settings.
-- **Export is client-side.** A widget's CSV is serialized in the browser from
+- **Chart-widget export is client-side.** A widget's CSV is serialized in the browser from
   data the widget has already loaded, so `allowExport` decides whether the action
-  is offered, not whether the viewer's browser holds the rows. The account-wide
-  **Allow data downloads** switch outranks it — see [Restricting data
+  is offered, not whether the viewer's browser holds the rows.
+- **One account-wide switch outranks `allowExport`.** **Allow data downloads** wins on
+  every surface `allowExport` grants, the Creator Mode report builder included — see
+  [Restricting data
   downloads](/admin/users-and-permissions/roles-and-permissions#restricting-data-downloads),
   which also notes that the per-user **Download data** role action is bypassed by
   anonymous embed viewers.
diff --git a/docs-mintlify/reference/control-plane-api.mdx b/docs-mintlify/reference/control-plane-api.mdx
index 0122386052f57..5f8f639093d4f 100644
--- a/docs-mintlify/reference/control-plane-api.mdx
+++ b/docs-mintlify/reference/control-plane-api.mdx
@@ -1,6 +1,6 @@
 ---
 title: Control Plane API
-description: REST surface for automating Cube Cloud deployments, environments, JWT issuance, and audit log export.
+description: REST surface for automating Cube deployments, environments, JWT issuance, audit log export, and dashboard PDF/PNG export.
 ---
 
 Control Plane API enables programmatic management of [deployments][ref-deployments]
@@ -371,6 +371,67 @@ curl \
   "https://YOUR_CUBE_CLOUD_HOST/api/v1/audit-logs/export?start=2024-01-01&end=2024-01-31&eventName=Logged+in&userEmail=user@example.com"
 ```
 
+### `/api/v1/deployments/{deployment_id}/dashboard-exports`
+
+Request a server-rendered snapshot of a whole published dashboard as PNG or
+PDF — the same rendering the [Download as PNG or PDF][ref-dashboard-download]
+action uses — without driving a browser through the console. A draft that has
+never been published can't be exported. Identify the dashboard with either
+`dashboardId` (numeric) or `dashboardPublicId` (string) — exactly one, not
+both. Requires **manage** access to the dashboard's workbook, the same
+permission the console's whole-dashboard download requires.
+
+Rendering happens asynchronously, since a capture waits for every widget on
+the dashboard to finish querying: submit a job, poll it until `status` is
+`completed` — or `failed`, whose `error` says why — then download the file.
+The job and its file are dropped at the `expiresAt` the submit returns —
+5 minutes out — so download before then or submit again. Only the identity
+that submitted a job can poll or download it.
+
+```bash
+# 1. Submit the export
+curl -X POST \
+  -H "Authorization: Bearer YOUR_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{"dashboardPublicId": "abc123", "format": "pdf"}' \
+  "https://YOUR_CUBE_CLOUD_HOST/api/v1/deployments/123/dashboard-exports"
+# -> { "jobId": "...", "expiresAt": "..." }
+
+# 2. Poll until it's done
+curl \
+  -H "Authorization: Bearer YOUR_API_KEY" \
+  "https://YOUR_CUBE_CLOUD_HOST/api/v1/deployments/123/dashboard-exports/JOB_ID"
+
+# 3. Download the file
+curl \
+  -H "Authorization: Bearer YOUR_API_KEY" \
+  -o dashboard.pdf \
+  "https://YOUR_CUBE_CLOUD_HOST/api/v1/deployments/123/dashboard-exports/JOB_ID/download"
+```
+
+An account administrator can also render the dashboard as if a specific other
+user opened it — `renderAs` a console user or an embed user — so the file
+reflects that person's own row-level security. An embed subject that doesn't
+exist yet is provisioned by the call; the `groups`/`userAttributes`/
+`securityContext` passed with it apply to that render only, never to the
+user's stored context. This is meant for scheduled, per-recipient reports:
+one API key produces a correctly-scoped file per person, instead of one key
+per person.
+
+Submitting returns `400` for a request that supplies both ids or neither,
+`404` for a dashboard that doesn't belong to the deployment or a deactivated
+console subject, and `403` when the account has
+data downloads restricted (not bypassed for an on-behalf-of export, unlike a
+built-in scheduled notification) or when an embed subject's tenant doesn't
+have the dashboard's workbook shared with it. It returns `429` when too many
+exports are already in flight for the identity being rendered as, so fan out
+per-recipient reports with a bounded number of jobs open at a time. See the
+[API reference][ref-api-reference] for the full request and response
+schema.
+
+[ref-dashboard-download]: /docs/explore-analyze/dashboards#download-as-png-or-pdf
+[ref-api-reference]: /api-reference/dashboard-exports/export-a-dashboard-as-png-or-pdf
+
 [ref-core-data-apis]: /reference/core-data-apis
 [ref-rest-api]: /reference/core-data-apis/rest-api
 [ref-metadata-api]: /reference/core-data-apis/rest-api/reference#metadata-api
diff --git a/docs-mintlify/reference/embed-apis/generate-session.mdx b/docs-mintlify/reference/embed-apis/generate-session.mdx
index c2aa54a2b73e3..73ca599f0fe68 100644
--- a/docs-mintlify/reference/embed-apis/generate-session.mdx
+++ b/docs-mintlify/reference/embed-apis/generate-session.mdx
@@ -1,6 +1,6 @@
 ---
 title: Generate Session
-description: HTTP reference for minting short-lived embed sessions that authorize external viewers under signed embedding without sharing API keys.
+description: HTTP reference for minting short-lived embed sessions that authorize external viewers under signed embedding without sharing API keys, and how to revoke one.
 ---
 
 The Generate Session API provides secure, session-based authentication for [signed embedding][ref-signed-embedding]. This API creates temporary sessions that allow external users to access embedded dashboards and visualizations without exposing your API keys.
@@ -17,6 +17,8 @@ The Generate Session API requires your [Cube Cloud API key][ref-api-keys] for au
 
 If the API key is [scoped to specific deployments][ref-api-keys], the `deploymentId` in the request body must be within the key's scope; otherwise the request is rejected with `403 Forbidden`. Unscoped keys can mint sessions for any deployment.
 
+The deployment-scope restriction above is specific to Generate Session; see [Revoke a session](#revoke-a-session) for how that endpoint's authorization differs.
+
 ## Endpoint
 
 ```text
@@ -61,6 +63,25 @@ Accounts are limited to 10,000 external users. To increase this limit, please co
 
 </Warning>
 
+### Response {#response}
+
+The API returns a session object:
+
+```json
+{
+  "sessionId": "abc123def456..."
+}
+```
+
+| Field       | Type   | Description                                            |
+| ----------- | ------ | ------------------------------------------------------ |
+| `sessionId` | string | Unique session identifier to use for embedding content |
+
+Use the `sessionId` directly in your embed URL to authenticate and load content securely.
+It is single-use and must be exchanged within 5 minutes; the token it's exchanged for is
+then usable for about 23 hours — see [signed embedding][ref-signed-embedding] — unless
+you revoke it sooner; see [Revoke a session](#revoke-a-session).
+
 ## Session settings
 
 `settings` is an object of per-session overrides for embed behavior, applied to
@@ -341,22 +362,6 @@ DELETE /api/v1/embed-tenants/{embedTenantName}/user-attributes/{id}
 
 These endpoints use the same `Api-Key` authentication as Generate Session and require admin access. List endpoints return cursor-paginated results (`?first=`, `?after=`).
 
-### Response
-
-The API returns a session object:
-
-```json
-{
-  "sessionId": "abc123def456..."
-}
-```
-
-| Field       | Type   | Description                                            |
-| ----------- | ------ | ------------------------------------------------------ |
-| `sessionId` | string | Unique session identifier to use for embedding content |
-
-Use the `sessionId` directly in your embed URL to authenticate and load content securely.
-
 ## Code Example
 
 <CodeGroup>
@@ -430,7 +435,51 @@ curl -X POST "https://your-account.cubecloud.dev/api/v1/embed/generate-session"
 
 Use session ID in [signed embedding][ref-signed-embedding].
 
+## Revoke a session
+
+```text
+POST https://{accountName}.cubecloud.dev/api/v1/embed/session/revoke
+```
+
+Call this from your application's logout handler to end an embed session from the
+server side. Pass the `sessionId` that Generate Session returned, and still remove the
+embedded iframe on logout — revoking a session doesn't tear it down on its own.
+
+```bash
+curl -X POST "https://your-account.cubecloud.dev/api/v1/embed/session/revoke" \
+  -H "Content-Type: application/json" \
+  -H "Authorization: Api-Key YOUR_API_KEY" \
+  -d '{ "sessionId": "abc123def456..." }'
+```
+
+Returns `204 No Content` on success, with no body.
+
+It requires an admin principal — an API key, embed JWT, or bearer token belonging
+to an admin user.
+
+<Warning>
+
+Unlike Generate Session, an API key's scope is **not** checked: the request body
+carries only a `sessionId`, so a key scoped to one deployment can revoke a session
+belonging to any deployment in the account.
+
+</Warning>
+
+Only tokens issued after this endpoint shipped carry the claim revocation checks
+against — an older token keeps working until its own signed expiry, 24 hours from
+mint (not the ~23-hour figure above, which is when the iframe itself stops
+trusting a token early). The `204` response is identical either way.
+
+Revocation covers the embed session only. A Cube API token the embed obtained from
+`POST /api/v1/deployments/{deploymentId}/token` is a separate credential and keeps
+working — revoke or expire it separately if your logout has to stop data-API access.
+
+See [Revoke an Embed Session][ref-revoke-session] for the full request and response
+reference, including the `204` idempotency behavior and the `403` when embedding isn't
+enabled for the account.
+
 [ref-api-keys]: /admin/account-billing/api-keys
+[ref-revoke-session]: /api-reference/embed/revoke-an-embed-session
 [ref-personal-api-keys]: /admin/account-billing/api-keys#personal-api-keys
 [ref-signed-embedding]: /embedding/iframe/auth/signed
 [ref-creator-mode]: /embedding/iframe/creator-mode