A workspace is the tenant everything in Bento lives under: runs, trajectories, signals, issues. From here you manage members, mint the API keys that push runs in and read data out, wire up where alerts get delivered, and tune how findings are extracted. In the dashboard this is Settings, and the CLI splits it across four command groups:Documentation Index
Fetch the complete documentation index at: https://docs.bentolabs.ai/llms.txt
Use this file to discover all available pages before exploring further.
workspaces, api-keys, notification-channels, and workspace-extraction-config.
The CLI signs in as you (
bentolabs auth login), not with an API key, so these owner-level commands work as your dashboard login does. API keys are a separate credential your app uses to send runs in.Most commands here need a workspace; set a default once with bentolabs workspaces use <ws-id> (see Installation). A few don’t: workspaces create / list, api-keys revoke, and the by-id notification-channel commands.Workspaces
Theworkspaces group lists the tenants you belong to and manages their members. In the dashboard this is Settings → General and Members.
| Command | What it does |
|---|---|
workspaces list | List the workspaces you belong to. |
workspaces create | Create a new workspace (no workspace selected needed). |
workspaces update | Rename the selected workspace. |
workspaces list-users | List the workspace’s members. |
workspaces remove-member <user-id> | Remove a member. |
name is the only field):
user_id:
API keys
A key is the credential your app uses to push OTLP runs into a workspace and read data back out, and it’s what you hand to the SDK or OTLP exporter. See Sources & sync for where runs come from. Keys are scoped to the selected workspace, and the dashboard lists them under Settings → API keys.| Command | What it does |
|---|---|
api-keys list | List the keys in the workspace (prefixes and metadata, never the secret). |
api-keys create | Mint a new key. The full secret is returned once, so copy it on create. |
api-keys revoke <key-id> | Revoke a key by id (not workspace-scoped). |
name, and the response carries the secret, shown only on create:
Notification channels
Anemail or slack target an incident can be delivered to, with a test send and a last-delivery status. In the dashboard these live under Settings → Notifications. list and create are workspace-scoped; get, update, delete, test, and get-last-delivery act on one channel by id.
| Command | What it does |
|---|---|
notification-channels list | List the channels in the workspace. |
notification-channels create | Create a channel (email or slack). |
notification-channels get <channel-id> | Read one channel. |
notification-channels update <channel-id> | Edit a channel: toggle, rename, rotate the webhook. |
notification-channels delete <channel-id> | Delete a channel. |
notification-channels test <channel-id> | Send a test notification. |
notification-channels get-last-delivery <channel-id> | The most recent delivery and its status. |
channel_type is required, and slack needs a config carrying webhook_url:
Extraction config
Per-workspace rules for how findings get extracted from runs: acanonical_view_whitelist (which parts of a run to surface as context) and keyword_rules (named keyword matchers). put is a full replacement. In the dashboard this lives under Monitoring settings.
put upserts both fields together:
See also
Sources & sync
Where runs come from. API keys authorize pushing them in.
Runs
The raw agent runs that land in a workspace.
Signals
The detectors whose firings notification channels deliver.