One core problem for digital asset programmes is integration friction: the platform has to sit inside systems operations, compliance, risk, reporting and technology already run, without forcing a full stack replacement for one new product line.
DALP 3.0 is built for that constraint. The v2 API gives integration teams a typed REST surface with filtering, sorting, pagination, idempotency keys and response-timing control. Long-running on-chain writes can return immediately with a status URL, so callers do not have to guess after a timeout. The same operating surface is available through the Console, API, SDK, CLI and MCP, under one permission model, the same validation and one audit trail.
Institutions do not adopt platforms in a vacuum. Replacing core infrastructure just to run one asset programme is rarely a realistic plan. The practical path is a controlled surface that existing teams can call from their own stack.
The v2 REST API lives at /api/v2. List endpoints use JSON:API-style filters and sorting, with offset pagination. Mutations take an Idempotency-Key so a retried write after an uncertain response runs once, not twice. Headers control participant identity, executor wallet routing and whether a transaction waits for settlement or returns a status URL to poll.
Blockchain writes are asynchronous first. The platform accepts the instruction, queues it on the durable transaction path and returns 202 Accepted with a status URL. That design survives a dropped connection, a restart or a slow chain. When a short interactive flow needs the result inline, send Prefer: wait=N (between 5 and 99 seconds). If settlement finishes inside the budget, the response comes back as 200 with the settled result. If the wait expires first, the call falls back to the same status URL. The TypeScript SDK defaults to a long wait on mutations, so client code usually receives the settled result; raw HTTP can opt into Prefer: respond-async instead.
Errors use a structured envelope across API, CLI and SDK: stable identifier, category, retryable flag, display message, cause and next step, with optional retryAfterSeconds. Calling code branches on category and retryability, not on parsed prose.
The v1 surface stays frozen at /api/v1 with unchanged shapes. Existing clients keep working. v2 is the path to filtering, idempotency and response-timing control. Product detail is in the DALP 3.0 v2 API documentation.
Operator work used to split across a console for people and an API for integrations. In DALP 3.0 those paths share the same contract. A console action maps to a v2 endpoint. The SDK wraps that endpoint with generated types. The CLI exposes the same operations as commands with matching flags. The CLI also serves as an MCP server, so an approved agent can discover tools available for its role and call them under the same permissions.
There is no separate agent API or automation mode. If a role can perform an operation, it can do so from the console, a script, the CLI or MCP. The TypeScript build enforces CLI coverage for every v2 route, so new platform capability does not ship only as a screen humans must click. That is what lets a pilot become an operating programme: more work can move into automation without inventing a second control model beside the platform.
Further detail is in the SDK, CLI and MCP documentation.
A pilot can live on console workflow for a while. A production programme cannot. Risk and compliance still need the same validations and audit trail when a scheduled job mints, a recovery process runs or an agent steps into a permitted path. Shared surface parity removes the usual gap where automation either scrapes a UI or bypasses controls through an ad-hoc wrapper.
The coverage span matters as much as the transport. Commands and endpoints reach compliance templates, trusted issuers, compliance providers, historical balances, yield schedules, exchange rates, identity recovery, token documents and paymaster policy configuration. Automation can stay inside product bias rather than freezing at token create and falling back to the console for everything after.
Move list and write traffic to /api/v2 when you need filters, pagination, idempotent retries or async settlement handles. Keep v1 only where clients are stable and feature needs have not forced the move. For mutations that can land twice under retry pressure, always send an Idempotency-Key and store it against your own job identifier. Prefer a status-URL flow for long writes; reserve short Prefer: wait budgets for interactive paths. Operate agents and scripts against the same role permissions and audit log as console users.
Related DALP 3.0 reading in this series: custody and signing, durable transactions and ledger history, and platform status monitoring. Start with the DALP platform overview for release context, the API getting started path, and the CLI overview.
Want to discuss how DALP connects to systems you already run?
Book a call with our team ↗
SettleMint, headquartered in Leuven, Belgium, with offices in UAE, Singapore and Japan is the company behind DALP, the entirely composable Digital Asset Lifecycle Platform. DALP enables financial institutions, market infrastructure operators, and governments to build, deploy, and manage digital assets and blockchain applications at scale.