CLI Reference

Complete reference for the dynamiq command. For installation and first-time setup, start with the CLI Overview. Command groups accept singular and plural aliases interchangeably: org/orgs, project/projects, workflow/workflows, app/apps, trigger/triggers, service/services, resource-profile/resource-profiles.

dynamiq [--version] [-v|--verbose] [-h|--help] <group> <command> [flags]

Options marked prompted are asked for interactively when omitted, so every command can run fully non-interactively in CI by passing its flags.

dynamiq config

Run without a subcommand to configure the CLI interactively:

dynamiq config

Prompts for the API host (Enter keeps https://api.getdynamiq.ai) and your API key — a Personal Access Token. Saved values are reused by all commands.

dynamiq config show

Print the current configuration with the API key masked:

dynamiq config show

Current Dynamiq CLI configuration:
DYNAMIQ API HOST: https://api.getdynamiq.ai
DYNAMIQ API KEY: dyn_...
DYNAMIQ ORG ID: 0d4f9a36-...
DYNAMIQ PROJECT ID: 7b1c2d8e-...

dynamiq org

dynamiq org list

List organizations your token can access, as an ID / Name table:

dynamiq org list

dynamiq org set

Set the current organization. Validates the ID against the API before saving it to your config:

dynamiq org set --id <org-id>

dynamiq project

Both commands require an organization to be set first.

dynamiq project list

List projects in the current organization:

dynamiq project list

dynamiq project set

Set the current project (validated against the API):

dynamiq project set --id <project-id>

dynamiq workflow

Build, check, run and release workflows from a flow JSON: the same DAG the editor saves, with nodes carrying a type, depends and an input_transformer.selector. Shorthand is accepted and normalised: a string in depends becomes {"node": ...}, a top-level selector moves under input_transformer, and a node without an id gets one. workflows is an alias of workflow.

dynamiq workflow node-types

List the node types the platform accepts, optionally filtered by a group such as agents, tools, llms, operators or utils. These strings are the only valid values of a node's type; the CLI keeps no list of its own, so run this before writing a flow rather than guessing:

dynamiq workflow node-types operators

dynamiq workflow validate

Check a flow JSON locally before it is saved, and exit non-zero on any error. Nothing is persisted, but the default run makes one request: it reads the platform's node types from /v1/agent-builder/nodes, with the configured host and key, to check each node's type. When that read fails, the check goes on without it and says so on stderr rather than failing. --offline skips the request, so a pre-commit hook or a job without network access or credentials can run the check as it is.

dynamiq workflow validate @flow.json

The platform drops unknown keys rather than rejecting them, so a misplaced selector yields an empty output instead of an error; the local check catches that before anything is persisted.

dynamiq workflow create

Create a workflow in the current project. {"name": "my-workflow"} is enough: a starter flow with one Input node and a matching canvas layout are generated, or pass your own flow to create it fully formed. Names are lowercase letters, digits and hyphens.

dynamiq workflow create '{"name": "claim-review"}'

dynamiq workflow save

Save the workflow DAG as its next version: on a workflow that already has versions this is what appends v2, v3 and so on, the API form of the editor's Save. It is the only command that persists nodes; updating a workflow's name or description leaves its flow untouched. A canvas layout is generated from the flow unless --flow-ui is given.

dynamiq workflow save <workflow-id> @flow.json

dynamiq workflow test

Run a flow with the given input without saving or releasing it. The flow executes for real, tools included, so choose an obviously-test input. A dry run, on by default, undoes afterwards what the run wrote into a vector store (the documents a writer ingested and a collection it created) and nothing else, so a page a tool created stays.

dynamiq workflow test @flow.json '{"claim": {"loss_type": "theft", "estimate": 2500}}'

dynamiq workflow release

Release a draft: the first release, which turns a workflow created with workflow create and never released into a versioned workflow. The endpoint takes a draft only and answers "Only draft workflows can be released." on a workflow that already has versions; from then on workflow save is what creates each next version. The workflow's current name, flow and layout are re-sent unless overridden:

dynamiq workflow release <workflow-id>

dynamiq workflow list, get, versions, verify

List the workflows of the current project, fetch one with its flow and layout, list its released versions newest first, or read a saved workflow back and check that the DAG persisted as written:

dynamiq workflow list
dynamiq workflow get <workflow-id>
dynamiq workflow versions <workflow-id>
dynamiq workflow verify <workflow-id>

dynamiq workflow flow-ui

Generate the canvas layout for a flow without saving anything, to inspect it or to merge in data the flow cannot carry:

dynamiq workflow flow-ui @flow.json --out flow_ui.json

Requirements

dynamiq workflow requirements, requirement-add, requirement-get, requirement-update and requirement-delete manage a workflow's requirements: the credentials each caller brings when the workflow is deployed for them.

dynamiq app

Deploy a released workflow as an app, call it the way an integration does, and inspect its deployments. apps is an alias of app.

dynamiq app deploy

Deploy a workflow as a new app in the current project. The response carries the app's id and its hostname, the endpoint the app serves:

dynamiq app deploy --name claim-review --workflow <workflow-id>

dynamiq app redeploy

Push a workflow, or a new version of it, onto an existing app, keeping its id and hostname:

dynamiq app redeploy <app-id> --workflow <workflow-id> --version <version-id>

dynamiq app invoke

Run a deployed app by POSTing to its own hostname, the way an integration calls it. The input is your Input node's fields, inline or read from a file, and is wrapped as {"input": {...}} unless that envelope is already there. The hostname is read from the app, and the call is authenticated with an Access Key taken from the DYNAMIQ_ACCESS_KEY environment variable (create one in the UI; the management token is not accepted by the app):

DYNAMIQ_ACCESS_KEY=<access-key> dynamiq app invoke <app-id> '{"fico": 720, "ltv": 80}'

dynamiq app list, get, deployments, delete

app list lists the apps of the current project, 25 per page with --all for every one; --workflow <id> narrows it to one workflow's apps and --include-archived adds the archived ones. app get <app-id> prints one app, hostname included. app deployments <app-id> prints its deployment history, the place to look when a deploy seems stuck. app delete <app-id> deletes the app with its triggers, after a confirmation.

dynamiq app requirements, requirements-status, connect-token

For an app whose workflow needs each end user to connect their own accounts: app requirements <app-id> lists what the app asks every user to connect, app requirements-status <app-id> <user-id> says what one user still has unsatisfied (a run for that user fails until nothing is), and app connect-token <app-id> <user-id> mints the single-use connect link that user follows to attach their accounts. The link is scoped to that user and that app and expires within minutes: hand it to that person and nobody else.

dynamiq trigger

Manage an app's triggers: a Pipedream event or a schedule that runs the app. A new trigger is created as draft and armed with activate. triggers is an alias of trigger.

dynamiq trigger create-schedule

Create a schedule trigger without writing the payload by hand. Pass exactly one of --cron or --run-at:

dynamiq trigger create-schedule <app-id> --name nightly --cron '0 2 * * *' --timezone Europe/Kyiv

dynamiq trigger create

Create a trigger from a JSON payload, inline or read from a file. name and config are required; provider is pipedream (the default, whose config needs the Pipedream trigger_id and takes configured_props) or schedule (whose config needs timezone and exactly one of schedule or run_at, with an optional expires_at). An optional input_transformer maps the event into the app's input.

dynamiq trigger create <app-id> @trigger.json

dynamiq trigger list, get, update, activate, deactivate, run, events, delete

trigger list <app-id> lists an app's triggers, a working config to copy from. trigger get <app-id> <trigger-id> prints one with its status (draft, active, inactive or expired). trigger update <app-id> <trigger-id> <payload> changes its config or input_transformer, never its provider. activate and deactivate arm and disarm a trigger. run fires an active schedule trigger once, now. events lists what a trigger has fired, the way to check it ran. delete removes a trigger after a confirmation.

dynamiq service

Manage service deployments — custom containers run on platform infrastructure.

dynamiq service list

List services in the current project with their ID, name, access type, category, and hostname:

dynamiq service list

dynamiq service get

Print all fields of one service:

dynamiq service get --id <service-id>

dynamiq service create

Create a service record in the current project:

dynamiq service create --name qa-service --access private

dynamiq service deploy

Start a deployment for a service — either building from a source directory (the default) or running a prebuilt image:

# Build from source: archives the directory and lets the platform run the Docker build
dynamiq service deploy --id <service-id> \
  --source ./ \
  --docker-file Dockerfile \
  --env-secret OPENAI_API_KEY "$OPENAI_API_KEY" \
  --env LOG_LEVEL info \
  --min-replicas 1 --max-replicas 3

# Or deploy a prebuilt image
dynamiq service deploy --id <service-id> --image registry.example.com/qa-service:1.0.0

With --source, the CLI packages the directory as a .tar.gz and uploads it with the deployment configuration to POST /v1/services/{id}/deploy; with --image it sends the configuration only. On success it prints Deployment successfully started with docker build. (or ... with image.).

dynamiq service status

Show the latest deployment of a service:

dynamiq service status --id <service-id>

dynamiq service update

Update a service's access type or description. At least one flag is required:

dynamiq service update --id <service-id> --access public --description "Public QA endpoint"

dynamiq service delete

Delete a service:

dynamiq service delete --id <service-id>

dynamiq resource-profiles

dynamiq resource-profiles list

List predefined container sizes you can pass to service deploy --resource-profile:

dynamiq resource-profiles list --purpose service

Next steps