CLI commands

OverviewCopy Anchor Link

The DALP CLI uses verb-first commands: dalp get tokens lists tokens, and dalp create tokens mints submits a mint. Most commands follow the public V2 API. Run dalp --help to see the commands available in your installed version.

A handful of top-level commands you will also reach for are hand-written instead of generated: login, logout, whoami, config, and org. Install and configure the DALP CLI covers those.

The verb-first patternCopy Anchor Link

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

create is the one verb worth a second look. It covers more than creation, because an instruction posted against an existing resource, minting against a token for instance, is a POST like any other and takes the same verb.

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

Static URL segments become command words; path parameters become positional arguments. For example, /tokens/{assetId}/mints becomes tokens mints <assetId> after the verb.

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: dalp get tokens with no argument lists tokens, and dalp get tokens <assetId> reads one. 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 enumerate the full command tree. The Platform API grows resource groups over time, and an unverifiable command in a reference page is worse than a missing one. Run dalp --help, or dalp get --help, dalp create --help, and so on, to list what your installed CLI version actually registers.

Not every API operation becomes a CLI command, and the exclusions fall into groups you can predict rather than a list you have to consult. An operation is left out when running it needs something a terminal does not have. That means a browser session, for an interactive sign-in or an OAuth redirect; an authenticator device, for a passkey or a wallet security ceremony; or an inbox click, for an email verification. For sign-in itself, dalp login covers CLI authentication instead of a generated auth command group. Two more groups have nothing to do with terminals. An operation is left out when it duplicates a capability the command line already reaches another way, which is why the administrative user and session routes appear once rather than twice. It is also left out when it is a Console form-validation probe or interface toggle with nothing to script against. Whatever the reason, dalp --help is the authority on what your own installed build registers.

Two further top-level groups, mcp and skills, come from the command-line framework the CLI is built on rather than from an API operation, so they answer to neither the generation rule nor the hand-written list.

Supply a body, query, or headerCopy Anchor Link

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.

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.

Mutations and settlementCopy Anchor Link

A create, patch, replace, or delete command that triggers an on-chain transaction asks the platform to wait for settlement. The command prints the settled resource if the write finishes during that wait. Otherwise, it prints a handle with transactionId (or requestId for a custody lifecycle write) and statusUrl. The message Request accepted; the transaction is still settling means the instruction remains in progress.

The CLI does not follow a handle for you. Follow it with the transaction's own stream, or read statusUrl until its status is terminal:

dalp get transaction-requests stream <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 backed by a streaming (Server-Sent Events) endpoint yields each event as it arrives instead of waiting for one final result. Use --format jsonl to consume that stream as newline-delimited JSON from a script.

Output and discovery for scripts and agentsCopy Anchor Link

Every command accepts --format (toon, json, yaml, md, or jsonl); see Install and configure the DALP CLI for the default and how to set it durably. Beyond formatting, the CLI carries a few discovery features built for scripted and agent-driven callers rather than a human running one command at a time:

• --llms prints a compact index of every registered command with its one-line description. --llms-full prints the same tree in full: help text plus a worked example for each command, the same content an installed skill file would carry.
• --schema on any leaf command prints its input and output shape as JSON Schema, covering both arguments and options, so a caller can validate before it runs the command.

Every command distinguishes a person running it interactively from an agent or script consuming it. In agent mode the same command reports progress as discrete status events instead of a spinner, and a streaming command emits each underlying event as its own line rather than one block at the end.

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 codesCopy Anchor Link

An error the CLI raises itself, before or after it calls the API, carries its own code string rather than a DALP-NNNN id. The ids in Error handling still apply to any failure response the API itself returns. A failed command returns its stable code and a suggested fix alongside the underlying error, not just a message, so a script can branch on the code without parsing a sentence meant for a person.