Automate DALP operations with CLI scripting

Choose when to automate DALP with the CLI, REST API, TypeScript SDK, OpenAPI specification, or MCP tools.

The DALP CLI can cover the same operating areas as the DALP API: token operations, user and identity work, compliance setup, feed updates, transaction inspection, and platform administration. Use the CLI when you need a command-line control plane for humans, scripts, CI jobs, or local AI assistants. Use the REST API or TypeScript SDK when an application or backend service needs stable request contracts, API-key authentication, generated clients, or webhook-driven reconciliation.

Choose CLI, API, SDK, OpenAPI, or MCP

Use the CLI for shell scripts, CI jobs, operational checks, setup tasks, and local automation. Authenticated commands use the instance saved by dalp login. Start with CLI getting started.
Use the REST API when a backend service, integration, or external workflow calls DALP directly. Authenticate with an API key in the X-Api-Key header, or with a browser session cookie where session-based authentication applies. Start with API getting started.
Use the TypeScript SDK when a TypeScript service needs typed DALP calls without hand-writing HTTP requests. Configure the generated client with an API key. Start with the SDK guide.
Use the OpenAPI specification when you need the complete route contract, API-tool imports, or client generation in another language. The OpenAPI routes use the same authentication as the API route you call. Start with the API reference and OpenAPI specification.
Use MCP tools when an AI assistant supports MCP and should call typed DALP tools instead of parsing shell output. MCP uses the authenticated CLI session that registers the MCP server. Start with CLI AI agent integration.

The capability split is about integration style, not a weaker command set. The CLI is the right interface for repeatable operator work and agent-assisted tasks. The API and SDK are the right interfaces for long-running services, application traffic, generated clients, and jobs that cannot keep an interactive CLI credential. All surfaces still enforce the caller's organisation context, permissions, and API validation.

JSON output for scripting

Set the output format to JSON for machine-readable responses:

## Per-command
dalp tokens list --format json

## Or set globally
dalp config set format json

Pipe to jq

## Get all token addresses
dalp tokens list --format json | jq -r '.[].address'

## Get the first admin's wallet
dalp users admin-list --format json | jq -r '.[0].wallet'

## Count tokens by type
dalp tokens list --format json | jq 'group_by(.type) | map({type: .[0].type, count: length})'

Environment-based configuration

Use DALP_URL when a command that does not require authentication needs to know the DALP instance, such as login or configuration setup:

export DALP_URL=https://your-platform.example.com
dalp login

Authenticated commands use the DALP instance stored by dalp login. Setting DALP_URL later does not retarget an already saved CLI credential. If a runner must operate against another DALP instance, run dalp login for that instance first.

For repeatable jobs, authenticate the runner once, then create a purpose-named API key from that authenticated session when a downstream integration needs direct API access:

## Create an API key from an authenticated CLI session
dalp auth api-key-create "ci-pipeline"

## Store the returned key in your CI secret store for SDK or REST API clients.
## Keep the runner logged in to the DALP instance used by CLI commands.

On Linux runners, the CLI stores its login credential in the DALP config directory with file permissions restricted to the current user. On macOS, it uses Keychain.

Scripting patterns

Token issuance script

#!/usr/bin/env bash
set -euo pipefail

## Create a bond token
result=$(dalp tokens create \
  --type bond \
  --name "Corporate Bond 2025" \
  --symbol CB25 \
  --decimals 18 \
  --countryCode 840 \
  --json '{"maturityDate": "2025-12-31", "couponRate": "5.5"}' \
  --format json)

address=$(echo "$result" | jq -r '.address')
echo "Token deployed at: $address"

## Mint initial supply to the treasury
dalp tokens mint \
  --address "$address" \
  --to 0xTREASURY... \
  --amount 1000000

## Grant supply management to operations team
dalp tokens grant-role \
  --address "$address" \
  --role supplyManagement \
  --account 0xOPS_WALLET...

User onboarding script

#!/usr/bin/env bash
set -euo pipefail

EMAIL="$1"
NAME="$2"

## Create user
user=$(dalp users create --email "$EMAIL" --name "$NAME" --format json)
userId=$(echo "$user" | jq -r '.id')
wallet=$(echo "$user" | jq -r '.wallet')

echo "Created user $userId with wallet $wallet"

## Register identity
dalp identities register --wallet "$wallet" --country US

## Create KYC version
version=$(dalp kyc version-create "$userId" --format json)
versionId=$(echo "$version" | jq -r '.id')

echo "KYC version $versionId ready for document upload"

Batch operations

#!/usr/bin/env bash
set -euo pipefail

TOKEN_ADDRESS="$1"
RECIPIENTS_FILE="$2"  # CSV: wallet,amount

while IFS=, read -r wallet amount; do
  echo "Minting $amount to $wallet..."
  dalp tokens mint \
    --address "$TOKEN_ADDRESS" \
    --to "$wallet" \
    --amount "$amount"
done < "$RECIPIENTS_FILE"

CI/CD integration

GitHub actions

name: Token deployment
on:
  workflow_dispatch:
    inputs:
      token_name:
        description: "Token name"
        required: true

jobs:
  deploy:
    runs-on: [self-hosted, linux]
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: "22"

      - name: Install DALP CLI
        run: npm install -g @settlemint/dalp-cli

      - name: Deploy token
        run: |
          dalp tokens create \
            --type equity \
            --name "${{ inputs.token_name }}" \
            --symbol "TKN" \
            --decimals 18 \
            --format json

This self-hosted runner example assumes the runner already has a DALP CLI login credential for the target instance.

For runners that cannot keep a CLI credential, use the REST API or TypeScript SDK with an API key secret for the write operation instead.

Error handling in scripts

The CLI exits with a non-zero code on errors. Use standard shell error handling:

#!/usr/bin/env bash
set -euo pipefail

if ! dalp whoami --format json > /dev/null 2>&1; then
  echo "Not authenticated. Run: dalp login"
  exit 1
fi

## Proceed with authenticated operations
dalp tokens list --format json

Project configuration

Create a .dalprc.json in your project root for team-shared settings:

{
  "apiUrl": "https://staging.example.com",
  "defaultOrg": "engineering",
  "format": "json"
}

This file can be committed to version control. Credentials are never stored in project config – they remain in the secure credential store.

Scripting and automation