LLM-friendly URL

Generate an Embed Authorization token

The first step to provide embedded resources in your application is to ensure you can securely authorize your application's end-users to access specific Luzmo resources & features, while also making sure they can only access the data they should have access to (e.g. multi-tenancy ). To do so, you should use an API key-token pair of an Organization Owner and use that server-side to request short-living Embed Authorization tokens. The result of this request is an Embed key-token pair that can be used to securely access specific Luzmo content client-side: Embedded dashboards or the dashboard editor, Flex widgets, or even Luzmo IQ.

⚠️

This "Create Embed Authorization" request needs to happen server-side . This is for security reasons: you do not want to expose your API key & token client-side, as that would mean that users would be able to change filters or grant access to your securables (dashboard and/or datasets) themselves.

Remember: Never use your API key and token client-side!

The API request is a 'create' request for an Authorization resource. In the snippet below, fill in your API key & token, add the user's details and the resources (collections, dashboards and or datasets) you want to give access to.

ℹ️

Create your API key & token in Luzmo in your profile settings .

embed.js
Shell
Node
Java
.NET
Python
PHP
import Luzmo from '@luzmo/nodejs-sdk';
const client = new Luzmo({
  api_key: '<your Luzmo API key>',
  api_token: '<your Luzmo API token>',
  host: 'https://api.luzmo.com'
});


const response = await client.create('authorization',
  {
    type: "embed",
    username: "<A unique and immutable identifier for your user>",
    name: "<username>",
    email: "<user_email>",
    suborganization: "<a suborganization name>",
    access: {
      collections: [
        {
          id: "<collection_id>",
          inheritRights: "use"
        }
      ],
      datasets: [
        {
          id: "<dataset_id>",
          rights: "use"
        }
      ],
      dashboards: [
        {
          id: "<dashboard_id>",
          rights: "use"
        }
      ]
    }
  }
);

Below you can find an initial list of properties you can specify here:

ℹ️

For a complete list of all possible properties you can specify in the Authorization request, check out the Authorization API resource .

Property Description
type
STRING
required
embed Use the value 'embed' for the token type you're requesting.
username
STRING
required
Identifies the user uniquely and immutably. This should correspond to eg. the primary key for the user on your end. If it changes, the user will not have access to their previously created content anymore. So don't use eg. an e-mail address if those can change in your platform! This will also be used to uniquely identify a Monthly Active Viewer (MAV) or Monthly Active Designer (MAD), depending on the token's role, for your Organization.
name
STRING
required
The full name of the user (i.e. First name and Last name). This will be used in our UI.
email
STRING
required
The email address of the user. This will be used in our UI.
suborganization
STRING
Each Embed token should be in a suborganization. The suborganization determines which other users they can see & interact with. This is typically a one-to-one mapping to your application's customer base; each end-user from a given customer would have the same suborganization value. If you want totally isolated users, set it to the unique username; if not specified, it will default to the username property of the token.
⚠ If set explicitly to null, the token will be in your main Luzmo organization rather than a suborganization, and would thus be able to see all users for your org and all suborgs; only use this for internal embed users that should be able to e.g. create dashboards in the embedded dashboard editor and share them across suborganizations via our UI! ⚠
access
Object
required
The access that the Embed token should have to a set of specific Dashboards and Datasets, optionally through one or more Collections. You must provide access to at least one resource. It's strongly recommended to always give the "maximum" access to resources, as some periodically triggered features (e.g. exports, alerts) make use of the access in the last requested Embed token for that end-user's "username".
collections
OBJECT
List of Collections that contain one or more securables (dashboards and/or datasets), to which the token should have access to. Note that the token will not have access to the Collection itself, but rather uses the Collection to access the underlying resources.
  • If a securable is added or removed from a collection, you must generate a new token (i.e the token gets access to securables inside the collection at the time of creation).
  • If you specify a securable in the dashboards / datasets property which is also accessible through a Collection that includes this dashboard / dataset, the more specific right is applied (i.e the right specified in the dashboards / datasets property overrides the inherited right via the Collection).
collection_id
UUID
ID of the collection through which you'd like to provide access to its underlying securables (i.e. dashboards & datasets).
inheritRights
STRING
The access rights the token should have to the dashboard(s) and/or dataset(s) inside the specified collection.
Note that the API token used to generate the embed token must have equal or higher access to the securables in the collection! If not, a warning message will be returned in the response to indicate that the embed token doesn't have access to one or more of the collection's securables.

Provides the following access to the securables inside the collection:
  • read:
    • dashboards: Can only view and interact with the dashboard and its items.
    • datasets: Can only query the dataset in the context of an existing dashboard item.
  • use:
    • dashboards: Can view and interact with the dashboard, as well as duplicate it or create variants in the embedded editor.
    • datasets: Can query the dataset freely (within the embed token's context). This is the minimal access required to be able to use the dataset in the embedded editor or in Luzmo Flex.
  • modify:
    • dashboards: Can view, interact, and modify this dashboard.
    • datasets: Can modify the dataset, e.g. creating new columns, changing column types, etc.
  • own:
    • dashboards: Can view, interact, modify, share, and delete the dashboard.
    • datasets: Can share and delete the dataset.
datasets
OBJECT
List of datasets the Embed token should have access to, with their individual access rights. If dataset(s) are specified which are also accessible through a specified Collection, the explicit dataset access rights specified here will override the inherited access right from the Collection.
dataset_id
UUID
Id of the dataset to which the Embed token should have access to
rights
STRING
The access right the embed token should have to the specified dataset. Note that the API token used to generate the embed token must have equal or higher access to the dataset!

Provides the following access to the dataset:
  • read: Can only query the dataset in the context of an existing dashboard item.
  • use: Can query the dataset freely (within the embed token's context). This is the minimal access required to be able to use the dataset in the embedded editor or in Luzmo Flex.
  • modify: Can modify the dataset, e.g. creating new columns, changing column types, etc.
  • own: Can share and delete the dataset.
dashboards
OBJECT
List of dashboards the token should have access to, with their individual access rights. If dashboard(s) are specified which are also accessible through a specified Collection, the explicit dashboard access rights specified here will override the inherited access right from the Collection.
collection_id
UUID
ID of the dashboard to which your token should have access to
inheritRights
STRING
The access rights the Embed token should have to the dashboard(s) and/or dataset(s) inside the specified collection.
Note that the API token used to generate the embed token must have equal or higher access to the securables in the collection! If not, a warning message will be returned in the response to indicate that the embed token doesn't have access to one or more of the collection's securables.

Provides the following access to the securables inside the collection:
  • read: Can only view and interact with the dashboard and its items.
  • use: Can view and interact with the dashboard, as well as duplicate it or create variants in the embedded editor.
  • modify: Can view, interact, and modify this dashboard.
  • own: Can view, interact, modify, share, and delete the dashboard.
expiry
DATE (RFC 3339)
Date/time when this authorization will cease working. To promote better security practices this property is required and enforced with a maximum expiry date of 1 year. It is advised to only use short-living token for maximum security. If not specified, defaults to 24 hours from token creation.
inactivity_interval
INTEGER
Duration of inactivity in seconds after which the token is prematurely invalidated. You can use this to invalidate tokens quickly when the session is ended (eg. all open dashboards are closed). If specified, a minimum value of 2 minutes is enforced to avoid undesired invalidation of a token due to e.g. missing a heartbeat signal sent by our server.
Defaults to 0 (i.e. no inactivity_interval).
role
STRING
The role of the Embed token. Defaults to role viewer if not specified. This is an important property for the embedded dashboard editor:

"viewer"
Embed token should only be able to view and interact with one or more dashboards, variants, and duplicates.

"designer"
Embed token should be able to create, edit, view and interact> with one or more dashboards, variants, and duplicates.

"owner"
Embed token should be able to create, edit, view and interact with one or more dashboards, variants, and duplicates. Next to that, they should be able to favorite dashboard variants for other Embed users within their suborganization.

More info under Embedded Dashboard Editor.

This returns a JSON object with an id/token combination that you can use to securely embed Luzmo content in your application/platform:

Response
json
{
  "type": "embed",
  "id": "< the embed authorization key >",
  "token": "< the embed authorization token >",
  "user_id": "< a uuid used on Luzmo's end to identify the embed user >"
  // ...
}

Handling multi-tenant data

Multi-tenancy is the ability of software to serve multiple clients. This means that depending on the client that logs into your platform, the embedded Luzmo content will only contain their relevant data .

There are multiple ways to implement this and Luzmo aims to provide a good solution for each of them. Setting up secure multi-tenancy in Luzmo happens via the Embed tokens and their properties.

Which specific properties are used depends on your data structure. Depending on your current data setup and use case, it might be necessary to dynamically:

More in-depth information about these features and how to implement them in Luzmo can be found in the Handling multi-tenant data section .

Allowing or denying access to a set of Luzmo features

For each Authorization token, you can specify a list of Feature flags that ensure your end-user can only perform a specific set of actions with that Embed token. This allows you to control which end-users can use e.g. the Exporting feature, configure Alerts, add datasets, etc.

ℹ️

For a complete list of all possible feature flags you can enable or disable, check out this Academy article . For a complete list of all possible properties you can specify in the Authorization request, check out the Authorization API resource .

In this Create Authorization request, we're specifying feature_overrides to deny the use of the Exporting and Alerting feature, but allow the user to connect their own Bigquery data source in the embedded dashboard editor

embed.js
Shell
Node
Java
.NET
Python
PHP
import Luzmo from '@luzmo/nodejs-sdk';
const client = new Luzmo({
  api_key: '<your Luzmo API key>',
  api_token: '<your Luzmo API token>',
  host: 'https://api.luzmo.com'
});


const response = await client.create('authorization',
  {
    type: "embed",
    username: "<A unique and immutable identifier for your user>",
    name: "<username>",
    email: "<user_email>",
    suborganization: "<a suborganization name>",
    access: {
      collections: [
        {
          id: "<collection_id>",
          inheritRights: "use"
        }
      ]
    },
    feature_overrides: ["!flag_alerting", "!flag_exporting", "flag_bigquery"]
  }
);

Prematurely invalidating Embed tokens

Embed Authorization tokens have an expiry (default when not specified: 24 hours from creation) and inactivity_interval (defaults to 0 when not specified) property that ensure any Embed token will expire at a given moment in time: you can control these properties when generating an Embed Authorization token .

If necessary, you can invalidate an Embed token prematurely using a "Delete" action on the Authorization API endpoint ; note that it can only be invalidated by using the Embed key-token itself to sign the request.

invalidate_token.js
Shell
Node
Java
.NET
Python
PHP
import Luzmo from '@luzmo/nodejs-sdk';
const client = new Luzmo({
  api_key: '<Embed authorization id>',
  api_token: '<Embed authorization token>',
  host: 'https://api.luzmo.com'
});

await client.delete('authorization', '<the authorization id>');
Did this page help you?
Yes No