The SDK types itself from the platform

The client still reads the way it did: dalp.api.token.read({ assetId }). What changed is everything behind that. Types now come from the platform's own route declaration rather than a contract maintained beside it. A call takes one flat object instead of a transport envelope, and a write asks the platform to hold the response, resolving with the settled resource or with the handle to follow.

One flat argumentCopy Anchor Link

A 3.1 call carried the transport in its argument, so where a field went was your problem at every call site.

3.1Copy Anchor Link

await dalp.token.read({ params: { tokenAddress } });
await dalp.token.list({ query: {} });

3.2Copy Anchor Link

await dalp.api.token.read({ assetId });
await dalp.api.token.list();

You name what you mean. The route declaration says which keys belong in the URL and which in the body, so the split is a lookup rather than something you spell out. A missing path parameter is caught at the call with the parameter and the route named, and a route whose every field is optional takes no argument at all.

The build refuses any route whose path parameter would collide with a body or query key, which is what makes merging them safe rather than merely convenient.

A write returns settled or hands you a handleCopy Anchor Link

A write here produces a real on-chain transaction, and the platform answers either with the settled result or with a 202 handle to follow. In 3.1 the SDK gave you waitForTransaction and you called it yourself once you recognised the accepted envelope. Every integration wrote that recognition slightly differently.

3.2 makes the two answers one shape. The call sends a bounded Prefer wait, so a write that settles inside it resolves settled; one that outlives it resolves with { transactionId, statusUrl } rather than throwing.

const result = await dalp.api.token.transfer({
  assetId,
  transfers: [{ recipient, amount }],
});
if ("transactionId" in result) {
  // Still in flight. Follow it -- do not resubmit.
  await waitForTransaction(dalp, result.transactionId);
}

The branch is the point. A wait that runs out is not a failure, and treating it as one tells a user their transfer failed while it is still on its way to the chain. The handle carries the transaction id and the status URL precisely so the caller can say "live" instead of "failed", and follow it with waitForTransaction or statusStream on its own budget.

TanStack Query, without a second moduleCopy Anchor Link

3.1 shipped no query integration, so every application wrote its own cache keys. Query and mutation factories now sit on the route nodes, beside the call:

const { data } = useQuery(dalp.api.token.list.queryOptions({ page: { limit: 50 } }));

The key is the route id plus canonicalized input. Two callers passing the same parameters in different key order therefore share one cache entry rather than fetching twice, and invalidating a route after a write is a prefix match. Nothing about the key is hand-written, which removes the class of bug where one character of difference silently becomes a second cache entry.

An Effect surface beside the promise oneCopy Anchor Link

Code written in Effect can import @settlemint/dalp-sdk/effect and get the same tree returning Effect values, with a tagged failure channel and interruption wired to the request rather than stopping at the await. The promise entry stays provably free of Effect, enforced by a build gate that walks the import graph, so the root SDK can be used without Effect.

Server rendering has a defined shapeCopy Anchor Link

Rendering on a server means deciding whether the render acts as the signed-in user or as your service. Forwarding the user's session is now a first-class option with the constraints that capability needs: destinations are allowlisted, redirects lose credentials the moment they leave the boundary, and a cookie-authenticated write is refused without a trusted origin.

TanStack Start, the Next.js App Router, server components, route handlers, and server actions are each documented with the wiring they need, including hydrating the browser cache from what the server already fetched.

What existing integrations must changeCopy Anchor Link

The namespace path is largely unchanged, so most call sites move rather than being rewritten. There is no compatibility layer, so plan the change as one piece of work.

Five changes need review during migration.

Assets are named by assetId. The token routes take the asset's address as assetId where 3.1 called it tokenAddress. The value is the same; rename the key at each call site.

Where the acting context lives. In 3.1, organizationId and idempotencyKey were client-level options, and idempotencyKey also had a per-call context override. They are headers now: the steady-state ones go in context at construction, and a single call overrides them through headers.

Idempotency keys on retried writes. Retain one key across all attempts to submit the same instruction. Generate a new key only for a new instruction. A header function runs on every request, so retain a retry key outside the function instead of generating it again.

Collection parameters. A list call takes page: { limit, offset }, sort, and filter. Prefix the sort field with - for descending order.

Settlement bounds. 3.1 sent Prefer: wait=99 on every mutation and left the rest to you. The SDK now derives the same header from settlementTimeoutMs, undefined asks for 15 seconds, and hands back whatever the platform answers, settled or a 202 handle. Set it to what your caller can actually wait for; the mutation factories already set a bound of their own.

Availability and compatibilityCopy Anchor Link

The SDK is published as @settlemint/dalp-sdk on npm and runs on Node 20 or later, on Bun, and in the browser. @tanstack/react-query and effect are optional peer dependencies; a consumer that uses neither resolves neither.

The Platform API itself is unchanged by this release. Every route, header contract, and error identifier the 3.1 client called is still there and still behaves the same way, so a migration is a change to your code rather than a coordinated change with the platform.

Start at the TypeScript SDK reference.

For a call-by-call route, argument, response, and removal map, see the 3.1 to 3.2 SDK migration mapping.