Embed a question, a dashboard, or an AI agent

Mint the token on your server

Your application already knows who the viewer is. Issue the token there, with the tenant identifier locked in, and hand the browser nothing else. This is the whole of the multi-tenant story.

curl -X POST https://bi.example.com/api/embed/tokens \
  -H "Authorization: Bearer $QRLY_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "resourceType": "DASHBOARD",
        "resourceId":   412,
        "lockedParams": { "tenant_id": "acme-gmbh" },
        "expiresInSeconds": 900
      }'

Render it in your page

Qrly.init takes the base URL of your installation, the token you just minted and a theme. Qrly.embed takes a selector and either a questionId or a dashboardId, plus any params that are not locked. The iframe reports its own height back over postMessage, which the SDK re-broadcasts as a DOM event so your layout code can react without listening on the raw message channel.

<div id="usage-dashboard"></div>
<script src="https://bi.example.com/embed/qrly-sdk.js"></script>
<script>
  Qrly.init({
    baseUrl: 'https://bi.example.com',
    token:   EMBED_TOKEN,       // minted server-side, short-lived
    theme:   'dark'
  });

  Qrly.embed('#usage-dashboard', {
    dashboardId: 412,
    params: { period: 'last_30_days' }   // viewer-supplied, never security-bearing
  });

  // iframe auto-resize is re-broadcast as a DOM event
  document.addEventListener('qrly:resize', (e) => {
    console.log('embed height', e.detail.height);
  });
</script>

The rule that matters

Anything in lockedParams is covered by the signature and is decided by your server. Anything in params is supplied by the browser and must be treated as untrusted — it is for periods, groupings and presentation, not for deciding whose rows come back. Qrly applies the same discipline to dashboard filters generally: a viewer can only supply a filter id and a value, never a column or an operator, and the binding operator comes from an allow-list.

One script tag, three attributes

The admin page issues an embed-agent token and hands back a copyable snippet. The token, the endpoint and the container element are the entire integration surface.

<div id="qrly-agent"></div>
<script
  src="https://bi.example.com/embed/qrly-agent.js"
  data-token="<embed-agent token>"
  data-endpoint="https://bi.example.com"
  data-container="#qrly-agent">
</script>

What the agent token carries

All of the following live inside the signed token, which has its own signing key and its own audience — separate from the question and dashboard embed keys, so revoking one does not disturb the other.

1. Agent type. Which of Qrly's agent personas the widget runs as. The embedded widget is not a general-purpose console.
2. Allowed connections. An explicit list. A connection that is not named cannot be reached, whatever the conversation asks for.
3. Allowed questions. An explicit list of saved questions the agent may run.
4. Allowed tools. An explicit list drawn from the agent runtime's tool set. Anything not listed is unavailable for that widget.
5. Locked params. The same mechanism as dashboard embedding — the customer scoping is signed in, not negotiated at runtime.
6. Per-session message cap and tool-call cap. A bounded conversation and a bounded amount of work per conversation.
7. Per-day session cap. Bounded exposure per token, per day, which is what makes a public-facing widget a defensible cost.
8. Greeting message, brand logo and brand colour. So the widget reads as part of your product rather than as a visitor from ours.
9. Active flag and revoked timestamp. Turn one widget off without touching the others.

Note what is not in that list: no way for the embedded page to widen its own scope. The allow-lists are claims in a signed token, and a browser that edits them invalidates the signature.