Skip to main content
The Generate Session API provides secure, session-based authentication for signed embedding. This API creates temporary sessions that allow external users to access embedded dashboards and visualizations without exposing your API keys.
The Generate Session API is available on Premium and Enterprise plans.

Authentication

The Generate Session API requires your Cube Cloud API key for authentication. The key must belong to an admin user: this endpoint mints a session for somebody else, choosing their identity and the groups and attributes their data access is resolved against, so a personal key is rejected with 403 Forbidden. If the API key is scoped to specific deployments, 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 for how that endpoint’s authorization differs.

Endpoint

Request Headers

Request Body

When using internalId, the user must already exist in Cube Cloud. You cannot specify groups, userAttributes, groupDefinitions, userAttributeDefinitions, securityContext, or userProfile with internalId — the internal user’s existing permissions are used instead.
Accounts are limited to 10,000 external users. To increase this limit, please contact support.

Response

The API returns a session object:
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 — unless you revoke it sooner; see Revoke a session.

Session settings

settings is an object of per-session overrides for embed behavior, applied to every embed opened with this session. Omit a key to inherit what the layer below says — the account-wide setting under Embed → Settings for the AI keys (except allowChatWorkspaceAuthoring, which has none) and for locale/timezone, the built-in default for the rest. The switches are tri-state: true/false pins the behavior for this session, taking precedence over whatever the layer below would have said. locale and timezone carry a value rather than a switch, and sit one step below the matching iframe URL parameter; a value Cube cannot use falls through instead of failing the session. The switches are signed into the session token, so a viewer cannot turn one back on; use them for anything that differs per customer. (locale and timezone grant nothing, and a URL parameter deliberately overrides them.) See Show and hide features for how they relate to the account-wide settings and the iframe URL parameters.
Chrome that belongs to a placement rather than to a viewer — the dashboard header and its controls, the workbook back button, chart export — is set with URL parameters on the iframe src instead, and is not accepted in this settings object. Show and hide features covers both layers together and the rule for choosing between them.
The Chat API has no settings object of its own. Of the keys above, its sessionSettings object accepts allowChatWorkspaceAuthoring and timezone, which mean the same thing there as settings.allowChatWorkspaceAuthoring and settings.timezone do here — except sessionSettings.timezone has no cube:action:set-timezone message, ?timezone= parameter, or dashboard-pinned zone above it to lose to; an unusable value still falls through to the deployment default rather than failing the session.

Branch selection

Omit branchName, or pass the deployment’s production branch, and the session queries production — the default. Pass any other branch and every Cube query the session makes — from embedded dashboards, the Creator Mode workspace, and chat alike — runs against that branch’s data model instead, which is how an embed previews data model changes before they ship. The branch is resolved when the session is generated, not when the iframe loads, so a bad branch fails the API call rather than the embed:
  • a name that isn’t a branch of the deployment returns 404;
  • a branch nothing is serving returns 400. A branch is served while someone has it open in Cube, or permanently once its staging environment is enabled.
Content itself isn’t branch-scoped: the same saved dashboards and workbooks render whichever branch the session selects.

User profile

userProfile lets you attach a human-readable display name and avatar to an external user so they render with a recognizable identity inside embedded surfaces (workbook owners, dashboard headers, etc.) instead of the raw externalId.
Behavior:
  • Both fields are persisted on the external user (keyed by externalId).
  • Sending userProfile on subsequent generate-session calls overwrites the previously-saved values.
  • Omitting userProfile (or omitting a property inside it) preserves whatever was saved before.

Picture format

The picture URL must be reachable by the end-user’s browser — it’s loaded directly via an <img> tag in the embedded UI, not proxied through Cube Cloud. The server validates only that the value is a syntactically valid http(s):// URL; it does not download or sniff the content. Use a URL that returns one of the common web image formats: PNG, JPEG, GIF, WebP, or SVG. Other content types (videos, PDFs, HTML pages) will fail to render and the avatar will fall back to the user’s initials. Practical guidance:
  • Prefer HTTPS URLs — mixed-content rules will block http:// images on HTTPS embed pages.
  • Keep the image under ~1 MB and ideally square (e.g. 96×96 or 256×256). Avatars are displayed in small containers, so anything larger is wasted bandwidth.
  • The URL must be publicly reachable — signed URLs that expire or assets behind auth headers will not load.
  • If the URL fails to load for any reason (404, wrong content type, CORS, network error), the UI gracefully falls back to an initials avatar derived from displayName. No error is returned to the caller.

User attributes

userAttributes is an array of { name, value } pairs that drive row-level security in queries.
Attribute definition lookup:
  • Read-only mode (creatorMode omitted or false): names are resolved against the tenant-wide attribute catalog (managed in Settings → User Attributes or via the admin GraphQL API). Any name not present there fails with User attributes not found.
  • Creator mode (creatorMode: true): names are resolved against the embed tenant’s scoped catalog (embed_user_attributes). Use userAttributeDefinitions in the same request to upsert definitions on the fly — see Creator mode bootstrap.
Rules:
  • Duplicate name entries are rejected with 400 Bad Request.
  • Values are persisted per user. Subsequent calls with the same externalId overwrite previous values for the supplied names.

Groups

groups is an array of group names (not IDs) that the user should belong to. Group definitions must already exist (or be created in the same request via groupDefinitions in creator mode).
Behavior: Group definition lookup:
  • Read-only mode: names are resolved against tenant-wide groups (managed in Settings → Groups or via the admin GraphQL API). The membership row references the global group.
  • Creator mode: names are resolved against the embed tenant’s scoped groups (embed_user_groups). Use groupDefinitions in the same request to upsert them.
If any name in groups cannot be resolved, the request fails with Groups with names <missing> not found.

Creator mode: bootstrapping groups and user attributes

In API-first integrations you often want to mint an embed session and define the groups/attributes it references in a single call, without first making a round trip to the admin UI. The groupDefinitions and userAttributeDefinitions fields do that — they idempotently upsert definitions in the embed tenant’s scoped tables and are validated before groups and userAttributes are applied. Both fields:
  • Require creatorMode: true.
  • Require an embedTenantName (definitions are only meaningful inside an embed tenant).
  • Require the useCreatorMode tenant flag — contact support to enable.
  • Land in the embed-tenant scope only — they never modify tenant-wide groups or attributes.
  • Are idempotent: running the same request twice produces the same end state.

groupDefinitions

Duplicate name entries within the same request are rejected.

userAttributeDefinitions

type is immutable. If a definition with the supplied name already exists with a different type, the request fails with cannot change type and nothing is upserted. This protects every value already stored against that attribute from silently becoming invalid. To change the type, delete the attribute via the embed-tenant admin API and recreate it. Duplicate name entries within the same request are rejected.

Bootstrap example

Define a group and an attribute, assign the user to both, and mint a session — all in one call:
A second call with the same body produces the same end state: the group and attribute already exist, descriptions/display names are reconciled if they changed, and the user’s memberships and values are re-applied.

Embed-tenant admin API

To list or delete the groups and attributes that have been bootstrapped into an embed tenant, use the admin endpoints scoped to that tenant:
These endpoints use the same Api-Key authentication as Generate Session and require admin access. List endpoints return cursor-paginated results (?first=, ?after=).

Code Example

Use session ID in signed embedding.

Revoke a session

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.
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.
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.
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 for the full request and response reference, including the 204 idempotency behavior and the 403 when embedding isn’t enabled for the account.