CLI

CLI Overview

Install and configure the dynamiq CLI — credentials, config files, and the org/project context that scopes every command.

The dynamiq command-line tool manages platform resources from your terminal: organizations, projects, workflows and their versions, apps and triggers, and service deployments. It talks to the management API (https://api.getdynamiq.ai by default) and authenticates with a Personal Access Token.

Install

The CLI ships with the SDK package — installing one gives you both:

pip install dynamiq
dynamiq --version

Configure

Run the interactive configurator once:

dynamiq config
Enter API host (press Enter to use default) [https://api.getdynamiq.ai]:
Enter API key:

Paste a Personal Access Token (prefix dyn_pat_) as the API key — create one under your account's Personal Access Tokens settings. Keep the default host unless you run a self-hosted Dynamiq deployment.

Verify what the CLI will use:

dynamiq config show
Current Dynamiq CLI configuration:
DYNAMIQ API HOST: https://api.getdynamiq.ai
DYNAMIQ API KEY: dyn_...
DYNAMIQ ORG ID: <not set>
DYNAMIQ PROJECT ID: <not set>

Where settings live

Settings persist in two JSON files under $XDG_CONFIG_HOME/dynamiq/ (defaults to ~/.config/dynamiq/):

FileContents
config.jsonorg_id, project_id — your current context
credentials.jsonapi_key, api_host

You can also supply credentials through environment variables: DYNAMIQ_API_BASE_URL and DYNAMIQ_API_TOKEN (the pair the platform sets inside an agent's sandbox), or DYNAMIQ_API_HOST and DYNAMIQ_API_KEY. A variable wins over the stored files, so a sandbox or a CI job can point the CLI elsewhere without touching them.

Set your context

Most commands are scoped to an organization and a project, mirroring how resources are organized on the platform. Pick both once; they are stored in config.json and reused by every later command:

# 1. Find and set your organization
dynamiq org list
dynamiq org set --id <org-id>

# 2. Find and set a project inside it
dynamiq project list
dynamiq project set --id <project-id>

org set and project set validate the ID against the API before saving, so a typo fails immediately rather than at deploy time. Commands that need a project — such as service create and service deploy — print No project ID found if you skip this step.

What the CLI covers

AreaCommandsPurpose
Configurationconfig, config showCredentials and host
Contextorg list/set, project list/setChoose the org and project
Workflowsworkflow list/get/create/save/test/release/versions/validate/verify/node-types/flow-uiBuild, check, run and release workflows from a flow JSON
Apps and triggersapp list/get/deploy/redeploy/invoke/deployments/delete/requirements/requirements-status/connect-token, trigger list/get/create/create-schedule/update/activate/deactivate/run/events/deleteDeploy a released workflow as an app, call it, and run it on an event or a schedule
Servicesservice list/get/create/deploy/status/update/deleteDeploy and manage custom containers
Resource profilesresource-profiles listBrowse predefined container sizes

Global flags work on every invocation: --version, -v/--verbose, and -h/--help (also available per command).

The node types a flow may use come from the platform, not from a list inside the CLI: dynamiq workflow node-types asks the API, so a node the platform learns, such as the Decision Table, Rules, Expression and Sub-workflow operators, is accepted by save, test and validate as soon as it is registered there. The CLI carries further families this reference does not cover yet (knowledge-base, connection, dataset, evaluation, integration, memory, skill, voice, database, inference and fine-tuning), which dynamiq <family> --help lists; every resource can also be managed in the UI or via the management API.

Next steps

On this page