CLI commands

The DALP CLI uses verb-first commands: dalp get tokens index lists tokens, and dalp create tokens mints <assetId> submits a mint. Most commands map to a public v2 Platform API route. Run dalp --help to see the commands available in your installed version.

The top-level commands login, logout, whoami, config and org are hand-written, not generated. Install and configure the DALP CLI covers those.

The verb-first pattern#

Every generated command path starts with a verb derived from the HTTP method. The API path's static segments follow the verb, and a variable part, like a token address, becomes a command argument instead.

create covers more than creation. An instruction posted against an existing resource, such as a mint against a token, is also a POST and takes the same verb.

These examples show the mapping between API routes and CLI commands.

The rule tells you what a command is called, not whether your machine has it. The tree is built from the API description inside the CLI build you installed, so deriving a command correctly and finding it missing means the build predates the operation. Pin the CLI version your automation expects and treat an upgrade as the moment new commands appear, rather than assuming a derived name is wrong.

A list endpoint and its matching single-item read endpoint share one command. When the resource also has nested commands, that shared command is named index: dalp get tokens index with no argument lists tokens, and dalp get tokens index <assetId> reads one. dalp get tokens alone prints the help for the commands under it.

Where the list and the single-item read differ by a trailing path parameter, the command declares both parameters, and only the trailing one is optional. Give it only the first argument and it sends the list request. Give it both and it sends the single-item request. get webhooks deliveries <webhookId> lists the deliveries of a webhook, and get webhooks deliveries <webhookId> <deliveryId> reads one. get token-compliance modules, get system addon-access-managers proposals and create tokens corporate-actions commit work the same way.

Every command supports --help, which shows its arguments and options and works through an example pulled from the same API description used to generate the command.

This page does not list the command tree. Run dalp --help, dalp get --help or dalp create --help to list what your installed CLI version registers.

Not every API operation becomes a CLI command. The CLI omits two operations that only the Console uses: a converter form-validation check and an invitation resend-dialog check. Sign-in is not a version 2 operation, so there is no generated auth command group, and dalp login covers CLI authentication.

Three further top-level commands, completions, mcp and skills, come from the command-line framework the CLI is built on rather than from an API operation, so they are neither generated nor part of the hand-written list.

Supply a body, query, or header#

An operation that takes a request body exposes it two ways at once. --body accepts the whole body as a single JSON value, and every simple top-level field of that body also gets an option of its own, so a short call needs no JSON at all. Fields that are nested, or that accept more than one shape, stay on --body only. Query parameters follow the same pattern, with --query as the whole-object escape hatch. Supply both --body and individual field options and --body wins outright, so build a call one way or the other rather than mixing them, and read dalp <command> --help for the options that operation's own body produced. --query overrides individual query options in the same way, but a query parameter the operation requires must still be passed as its own option, because the JSON object alone does not satisfy it.

A command built from an operation that declares header parameters exposes those headers as ordinary command options, lower-cased and hyphenated from the header's own name. A header the operation calls Idempotency-Key becomes the option --idempotency-key, settable per call without changing the command's own shape.

--format <value> with a space selects CLI output and refuses any value outside the five formats. A route with its own format query parameter takes --format=csv, --format=xlsx or --format=pdf, as that route supports. The command does not save the response body, so a route that answers with file bytes prints null. Download those files through the API or the SDK.

Mutations and settlement#

A create, patch, replace, or delete command that triggers an on-chain transaction asks the platform to wait up to 15 seconds for settlement. The command prints the settled resource if the write finishes during that wait. Otherwise, it prints a handle with statusUrl and either transactionId or, for a custody lifecycle write, requestId. The message Request accepted; the transaction is still settling means the instruction remains in progress. A write held under maker-checker, the control in which a second person approves what one person raised, reports Request held for a second approver instead.

The CLI does not follow a handle for you. Read the transaction request until its status is terminal, which for an EVM transaction is COMPLETED, FAILED or CANCELLED, or DEAD_LETTER with mayStillLand set to false. While mayStillLand is true, keep reading and do not send the write again:

dalp get transaction-requests index <transactionId>

Pass --no-wait to skip the hold and take the handle back immediately:

dalp create tokens mints <assetId> \
  --body '{"amounts":"1000","recipients":"0x8ba1f109551bD432803012645Ac136ddd64DBA72"}' \
  --idempotency-key mint-example-001 --no-wait

A command run with the stored API key sends no wallet verification, because the platform does not ask an API-key request for it. The account's roles and any maker-checker hold still apply. Send the same --idempotency-key with the same body to retry the write, and Idempotency and async settlement describes what a repeat returns.

A command backed by a streaming (Server-Sent Events) endpoint, such as dalp get transaction-requests stream <transactionId>, prints each event of the stream as it arrives and exits when the stream ends. Under --format jsonl every event is its own line. When the stream fails before it ends, the command prints the API error with its Why and Fix lines and exits with code 1.

Output and discovery for scripts and agents#

Every command accepts --format (toon, json, yaml, md, or jsonl). See Install and configure the DALP CLI for the default. The CLI also has global options and discovery features for scripts and agents:

• --llms prints an index of every registered command with its description, and --llms-full prints the same tree with each command's help text, arguments, options and worked example.
• --schema on a leaf command prints its arguments and options as JSON Schema, so a caller can validate before it runs the command.
• --filter-output keeps only the output keys you name, --full-output prints the whole output envelope, and --token-count, --token-limit and --token-offset measure or bound what a model reads.

Every command distinguishes a person running it interactively from an agent or script consuming it. A run is in agent mode when standard output is not a terminal or a --format flag is present. In agent mode the same command reports progress as discrete events ahead of its result instead of a spinner, and piped output carries the events too. Output format gives the shape each --format prints.

Using the CLI with AI agents covers registering dalp as an MCP server and as an agent skill, which build on these same features.

CLI-local error codes#

An error the CLI raises itself, before or after it calls the API, carries its own code string rather than a DALP-NNNN id. When the API or the SDK supplies a code, that code is the one your script sees, so branch on the codes in Errors for any failure response the API itself returns. A failed command exits with status 1 and prints its code and message, so a script can branch on the code without parsing a sentence meant for a person. It also prints the cause, after Why:, and a suggested fix, after Fix:, followed by commands that may help. A generated command adds these lines to the end of its message, so they appear in every output format. A hand-written command prints them as a separate cta block.