Authentication
:::caution Products do not share credentials
KOBANA_TOKEN holds one product's credential at a time. A Magic Dashboard token does not authenticate against any other Kobana product, and vice versa. kobana auth login belongs to the Banking Gateway and does not issue Magic Dashboard tokens.
:::
The token
Magic Dashboard authenticates with an RS256 access token issued by Kobana's authorization server (account.kobana.com.br), sent as Authorization: Bearer <jwt>. The token's aud is https://api.dashboards.kobana.com.br — which is why it only works for this product. The API only verifies tokens and issues none: see API Authentication for how to get one.
The scope claim decides what the token can do:
| Command | Accepted scopes |
|---|---|
Read (GET) | read, write or all |
Write (POST, PUT, PATCH) | write or all |
Delete (every DELETE, data-purges delete included) | delete or all |
Import (imports create, entities records import create, workspaces import create, backups restore) | import or all |
Export (exports create, exports download, backups download, workspaces export) | export or all |
No level stands in for another: write does not delete, import or export. With resource scopes (dashboards/{group}), the level applies only within the groups the token carries — see API Authentication.
Without the right scope the answer is 403 insufficient_scope. A token issued to a person is also bounded by what that person's role allows in the dashboard (403 insufficient_permission); a machine token acts for the organization.
Put the token in KOBANA_TOKEN before calling the product — me list shows who it belongs to:
export KOBANA_TOKEN=$JWT_DASHBOARDS
kobana dashboards me list
Since the variable is the same for every product, export it per command (or use a per-project .env) if you switch products in the same session:
KOBANA_TOKEN=$JWT_DASHBOARDS kobana dashboards data-sources list --fields "id,name,status"
Workspace (X-Workspace-Id)
The token identifies the organization; its data lives in workspaces, and the X-Workspace-Id header says which one the call acts on — the id or public_id shown under Workspaces in the dashboard (or by kobana dashboards workspaces list). It may be left out while the organization has a single workspace; with two or more, leaving it out returns 400 workspace_required. A workspace from another organization returns 403 unknown_workspace, and a person token without access to the workspace, 403 workspace_access_denied.
The CLI fills the header from KOBANA_WORKSPACE_ID. To act on another workspace for a single call, pass the header in --params, which wins over the variable:
export KOBANA_WORKSPACE_ID=WORKSPACE_ID
kobana dashboards entities list
kobana dashboards entities list --params '{"X-Workspace-Id": "OTHER_WORKSPACE_ID"}'
--dry-run shows the headers that would be sent (without the token), and kobana schema lists each endpoint's headers under header_params.
Resolution priority
| Priority | Method | Configuration |
|---|---|---|
| 1 | Direct token | KOBANA_TOKEN |
| 2 | Credentials file | KOBANA_CREDENTIALS_FILE |
| 3 | Saved credentials | kobana auth login (Banking Gateway only) |
Environment
Magic Dashboard has a single environment, production, which is the CLI default — there is no need to pass --env.
| Environment | API | --env |
|---|---|---|
| Production | api.dashboards.kobana.com.br | production (default) |
Magic Dashboard has no sandbox and no development host of its own: with --env development the CLI falls back to production.
kobana dashboards workspaces list
Next steps
- Usage — syntax, resources, examples.
- Environment variables — the full reference, including config and logging.