Overview
An embed link puts one dashboard inside another application. The link is a credential in its own right: it grants read access to that single dashboard and nothing else, it can be revoked at any time, and it never exposes an API key. Use it when you want a dashboard to appear inside a Power BI report, a Tableau dashboard, a Confluence page, or your own product.Embed links currently cover dashboards. Data apps have their own embed flow, described in Embedding Data Apps.
Creating a link
Create the link from the dashboard’s share menu, or through the API:Embedding the link
Drop the URL into an iframe:Who the dashboard runs as
The link republishes the access of the member who created it. Viewers are anonymous: they do not log in, and they inherit exactly the data that member can see. Access is re-checked on every load rather than frozen at creation. If the creator loses access to the dashboard, or leaves the organization, the link stops working. Revoking the link stops it immediately. Because anyone holding the URL sees the dashboard, treat it like a password: put it only on pages whose audience should see that data.A plain link shows every viewer the same data. If each viewer should see only their own rows, use a per-viewer link instead, described below.
Per-viewer links (row-level security)
A dashboard’s live queries can scope to whoever is looking at it: the viewer’s identity reaches governed TQL as_tql.client_attributes_json, so one dashboard shows each person their own rows. A plain embed link has nobody to identify, so those queries get no identity and TQL written the recommended way fails closed.
To keep that scoping in an embed, create the link with Scope each viewer separately checked, or pass requireSignedViewer: true to the API. You get a signing secret once, alongside the URL.
Your backend then signs one short-lived token per viewer with that secret:
- A link created with this option rejects the plain URL. The signed token is the only way in, so nobody can drop the identity by trimming the URL.
- Tokens must carry an
exp, and must be signed with HS256, HS384, or HS512. Unsigned tokens are rejected. - Your
expbounds the session. The embed stays authenticated until the token expires or fifteen minutes pass, whichever comes first, so a five-minute token gives a five-minute view. Set it to how long a viewer should be able to sit on the page, and reload with a fresh token for longer sessions. client_attributesmust serialize to 2KB or less, since it travels in a cookie.- Only queries run through the live query path see the viewer. Data prepared when the dashboard starts is one snapshot shared by everyone, so build RLS dashboards on live query sources.
- These queries are attributed to an embed viewer rather than to the link’s creator, so the audit trail does not claim the creator ran them.
Expiry and revocation
Links do not expire unless you set an expiry when creating one. Revoke a link from the dashboard’s share menu, or:How the embed authenticates
Worth knowing if your security team asks:- The wrapper page exchanges the link token for a capability cookie scoped to the single sandbox worker serving that dashboard. The cookie authenticates the dashboard’s own asset and websocket requests, which browsers will not attach an
Authorizationheader to. - The cookie is not a session. It cannot call the API, reach another dashboard, or act as the member anywhere else.
- It is
HttpOnly,Secure, and partitioned per embedding site, so another site cannot replay it. It expires after fifteen minutes and the page silently renews it while open. It also names the link that issued it, which is what makes revocation immediate rather than waiting for expiry. - No API key is ever sent to the browser.