From 3.2 your back office builds on a v2 API that breaks only on a new API version, or after a deprecation with at least 90 days' notice. The promise covers the v2 API that 3.2 publishes, and reaching it removes 187 operations that 3.1 published, 42 of them with no v2 successor. The TypeScript SDK is generated from the same routes, and each webhook endpoint receives its events in order. The payloads of the event families 3.2 adds, apart from gas funding requirements, are beta and can still change inside v2. Once your organisation connects its own Xero app, DALP posts each final money event your rules map to that Xero ledger, once.
A v2 contract that holds from 3.2, and a client generated from its public routes
A breaking change ships on a new API version, next to the one you call, and an operation leaves v2 only after its sunset date. The SDK's types come from the same declaration as the routes they call.
- v2 API
- Stable from 3.2
- Deprecation notice
- At least 90 days before a sunset
- Webhooks
- In order, per endpoint
- From the 3.1 SDK
- Code changes needed for 3.2
Before and after
Before 3.2: in 3.0 and 3.1, v2 could change between releases, so an upgrade could move a field or drop an operation that a back-office job relied on. Webhook events carried no sequence per endpoint, so a consumer that posts to a ledger had to put them in order itself.
With 3.2: v2 follows a written contract: no new required input, no narrowed input and no removed response field inside the version, and an operation leaves v2 only after a deprecation that gives at least 90 days' notice. A build check refuses a removed operation or parameter and a newly required input, and review catches a narrowed input or a removed response field. An operation that is going away says so on every response. The SDK and the CLI are generated from the public v2 routes, most reads can be revalidated with an ETag, and each webhook endpoint receives its events in sequence.
Your back office calls the v2 API through the generated SDK, reads revalidate with an ETag, and each webhook endpoint receives signed events in order.
Build against a v2 contract that holds from 3.2
From 3.2, the versioning policy keeps breaking changes off v2: a breaking change ships only on a new API version, served next to the current one, and an operation leaves v2 only after its sunset date. A Developer at the bank finds out early when an operation is going away. Every response from it, error responses included, carries the Deprecation and Link headers, and the Sunset header once a sunset date is set. That date is at least 90 days after the deprecation, the Link header names each successor path, and the OpenAPI contract marks the operation deprecated, so the team plans the move on a known date. /api/v1 takes no new operations, and 3.2 removes three v1 user and wallet operations and the single-wallet fields on v1 user reads, each with its successor in the integration upgrade guide. A release can still add operations, response fields and new errors inside v2, so a client handles errors by their class and the retryable flag and ignores fields it does not know.
Your integration team sees each endpoint's deliveries and success rate.
Call the API through a client generated from its routes
The SDK's route tree and types are generated from the platform's public v2 routes, so the compiler catches a call whose shape the platform would refuse. Every route sits under dalp.api and takes one flat object, as in dalp.. A write resolves with the settled resource, or with a handle carrying transactionId and statusUrl when it has not settled within its wait, and every route has TanStack Query factories whose cache keys the SDK derives from the call. The dalp CLI is generated from the same routes and puts the verb first, as in dalp get contacts. A Developer upgrades the package, compiles, and gets a type error at each call, import and option that changed. Code written against the 3.1 SDK does not compile unchanged, and the SDK migration guide lists each change. Venue setup, trade busts and venue report replay are in the v2 API reference but have no SDK operation, so a client calls them over HTTP.
Read again only what changed
With response caching on, as it is by default, most v2 reads return an ETag, as response caching describes, so a client asks whether a resource changed instead of downloading it again. A reporting job that polls positions every minute sends the stored tag in If-None-Match and gets 304 with no body while nothing changed. Cached responses are kept apart per caller, by organisation, user, roles and the participant the request acts as. After a write, that user's reads wait for the cache to catch up for a configurable window, 60 seconds by default, so the job never reads data from before its own write. Some reads, such as custody reconciliation and deposits, carry no tag, as which reads carry a tag lists, so a client stores a body without one and reads it again in full.
Receive events in the order they happened
Each webhook endpoint receives its events in the order the platform produced them. Every event takes the next number in the endpoint's own sequence and waits while an earlier event for that endpoint is still pending, and a retraction waits until the event it corrects has been delivered or settled. 3.2 adds event families for fees, corporate actions, venue order status, announcements and settlement fills, compliance verdicts, gas funding requirements, operations cases, role grants that are about to expire, custody gateway deposits and withdrawals, and bank rail credits and cash-outs. Every event name is in the public catalogue at /., and a subscription that names no published event is refused when the endpoint is registered. A Developer subscribes the bank's ticketing endpoint to operations.case.*, so each case an operator works in the Console opens and closes a ticket without polling. A ledger subscribed to token.fee.final posts fees in the order the platform recorded them. Delivery is at least once, so a consumer removes duplicates by the event's id. A pending event holds the later ones until it is delivered, fails for good or reaches the end of its three-day retry window, and an event that waits for chain finality holds nothing back, so it can arrive after events recorded later. Apart from gas funding requirements, the event families 3.2 adds are beta in the event reference, which means their payloads can still change inside v2.
Post each money event to your Xero ledger once
Your organisation's books stay in its own Xero ledger, and DALP posts the money movements to it. An organisation administrator connects the organisation's own Xero app while signed in to the Console, so the deployment holds no shared Xero credentials. DALP then posts each final money event the organisation's rule table maps, such as a trade settlement, a fee, a bank rail credit or cash-out or a paid dividend, as one Xero manual journal, and posts it once, across retries, crashes and configuration changes. The organisation's posting policy sends one journal per trade, the default, or one balanced journal for each day. A trade bust or another retraction posts as the reversal of its original journal, on the same Xero account codes the original used, even when the account mapping changed after the original posted. Every event leaves a posting record that says what happened to it, and an event that cannot post raises an “Accounting event blocked”, “Accounting posting failed” or “Xero connection needs attention” case, which your team works with its other operations cases in the Console. DALP never chooses accounts. It posts nothing until the organisation stores its rule table, account mapping and posting policy and connects Xero, and the deployment must be able to reach Xero. In 3.2 DALP does not post mirror-token issuance and burn, or the coupon and maturity redemption cash paid on each claim. Post DALP events to a ledger →
Your organisation's owner reads every posting record on the Console's “Accounting” page under Organisation settings: what posted and to which Xero journal, what is still waiting, and why a record failed, in plain words next to Xero's own message. When Xero refuses a journal, the owner fixes the cause in Xero or in the configuration and selects “Retry posting”. DALP checks Xero for a journal it already sent before it builds one again, so a retry never posts the same journal twice, and an event no rule covered is decided again with the newest configuration. An integration reads and retries the same records through the v2 API.
The v1 API cannot bypass maker-checker
When an organisation protects a group of changes with maker-checker, a v1 write whose v2 route that group would hold is refused with 403 before anything runs, and the refusal names the v2 route that can hold it for a second user. Four v1 writes gain a 403 they did not publish before: registering an external token, requesting a KYC profile update, creating a user and revoking a user's session. v1 writes under maker-checker →
Upgrading
The breaking changes land in 3.2 itself, before the v2 rule takes hold. Regenerate your client from the 3.2 OpenAPI document and compile: 187 v2 operations that 3.1 published are removed, 145 of them with a successor, some v2 requests gain required fields, and some response rows change shape. Existing routes also gain new refusals, which no compiler shows. Three v1 operations are removed, v1 user reads lose their single-wallet fields, and a v1 write is refused while maker-checker protects its v2 route. Error bodies drop the defined field on both versions, and CLI scripts move to the verb-first commands. A client that retries webhook registration with the same idempotency key gets the first endpoint back, without its signing secret, so store the secret from the first response. Upgrade an integration to DALP 3.2 lists every change with its successor and how to detect it.
Why it matters
- Banks: core-banking and reporting integrations built on v2 hear about each deprecation on every response, with the successor named, long before anything goes away.
- Exchanges, CSDs and market infrastructures: post-trade and surveillance systems receive order, settlement and corporate-action events in sequence per endpoint.
- Partners: A partner generates its client from the same OpenAPI contract and receives webhook events signed and in order per endpoint.