Skip to main content

Changelog

All notable changes to the DLTM Derivatives API.

This changelog follows Keep a Changelog conventions.

2026-09-08 — v1.14.1​

Changed​

  • Exchange error messages. When the exchange rejects a request, the message in the error response is now taken from a fixed catalogue of DLTM wording instead of forwarding the venue's own text. code values are unchanged; only the wording is stabilised, so clients should match on code, not on message.
  • POST /customers/{customer_code}/orders — the 400 response now documents how code distinguishes the cause: VALIDATION_ERROR for a malformed request, ORDER_REJECTED when a well-formed order is refused by the exchange (invalid price or quantity for the instrument, notional above the venue maximum), INSUFFICIENT_FUNDS when collateral is insufficient. A 404 NOT_FOUND is returned when the symbol does not exist or is not available to the broker.
  • DELETE /customers/{customer_code}/orders/{reference_id} — cancelling an order the exchange does not know returns 404 NOT_FOUND instead of a 400.
  • POST /customers/{code}/deposits and POST /customers/{code}/withdrawals — amount accepts at most 8 decimal places. More precise amounts are rejected up front with 400 VALIDATION_ERROR ("amount must have at most 8 decimal places") instead of an opaque exchange error. An unknown asset is likewise rejected with 400 VALIDATION_ERROR.
  • PUT /customers/{code}/fee-profile and PUT /customers/{code}/fee-profile/{symbol} — at least one of maker_fee / taker_fee is required, and each supplied value must be a decimal number in basis points (an optional leading - marks a rebate).
  • POST /customers/{customer_code}/orders — limit_price is required and must be positive for limit orders and is rejected on market orders; trigger, stop-limit, take-profit and stop-loss prices must be positive decimals. Violations return 400 VALIDATION_ERROR before the order reaches the exchange.
  • balance-changes channel — pending events are no longer pushed. Each movement is now emitted exactly once, on its transition into a terminal status (completed or cancelled), so consumers that dedup by code always receive the terminal event. The pending state itself is unchanged and remains visible in the withdrawal create response and on GET /customers/transactions.

Fixed​

  • leverage on POST /customers/{customer_code}/orders — the documented pattern now matches the enforced range 1–13 (it previously allowed values up to 999 that were rejected at runtime).
  • reference_id path parameter on GET/DELETE /customers/{customer_code}/orders/{reference_id} — now carries the same constraints as the field on order creation (max 40 characters, ^[a-zA-Z0-9_\-]+$).

2026-08-31 — v1.14.0​

Added​

  • symbol on GET /trades and GET /customers/{code}/trades — filter the list by instrument symbol (exact match on the internal form, e.g. BTCUSDC_PERP). An unknown symbol returns an empty page.

Changed​

  • Nonce rules for REST and WebSocket authentication. X-Nonce (and the WS authenticate nonce) is now validated as a nanosecond Unix timestamp against server time instead of against the last value we accepted. A nonce is accepted when it is no more than 30s behind server time, no more than 5s ahead of it, and has not been used before by the same public key.

    Nonces no longer have to increase. Requests may be signed concurrently and arrive in any order, so no cross-request coordination is needed — previously a request that overtook another in flight was rejected even though both nonces were valid.

    Action required if your nonce is not a real timestamp. A persisted counter, a small increasing integer (1, 2, …) or a millisecond timestamp used to be accepted and now returns 401 on every request. Send time.Now().UnixNano() (or your language's equivalent) and keep the host clock synced; the Date response header carries server time to compare against.

    REST and WebSocket still share one nonce namespace per public key, so do not reuse a value across the two.

Fixed​

  • GET /trades — unsupported query parameters were silently ignored, returning the unfiltered broker-wide list. They are now rejected with 400 VALIDATION_ERROR naming the offending parameter and the supported set. In particular, start/end senders get pointed at from/to, the range names both trade endpoints use.

2026-08-19 — v1.13.0​

Added​

  • GET /trades — broker-scoped trade list across all of the broker's customers, with the same filters and pagination as GET /customers/{code}/trades, plus an optional customer_code query parameter to scope results to a single customer.
  • customer_code on trade records — returned by GET /trades, GET /customers/{code}/trades and GET /customers/{code}/trades/{trade_code}.
  • sort query parameter on GET /customers/{code}/trades — asc (oldest-first) or desc (newest-first, the default). Results were previously always newest-first regardless of any supplied sort value; the default is unchanged.

Changed​

  • A withdrawal is now reported as pending before it transitions to completed — in the create response, on GET /customers/transactions and on the balance-changes channel. This is the lifecycle deposits have always had. Its code is stable across the whole lifecycle, so a balance-changes event still joins back to its ledger entry by code.

Fixed​

  • POST /customers/{code}/withdrawals — withdrawals were failing with 400 VALIDATION_ERROR after an upstream rule change; they succeed again.

2026-08-03 — v1.12.3​

Fixed​

  • GET /customers/transactions and GET /customers/{code}/transactions — created_from/created_to now also accept milliseconds since epoch, the format every other date-range query parameter (start/end) uses, in addition to the previously accepted RFC 3339 date-time. Millisecond values were previously rejected with 400 VALIDATION_ERROR.
  • GET /customers/{code}/trades — from/to likewise now accept milliseconds since epoch in addition to an RFC 3339 date-time.

2026-07-23 — v1.12.2​

Fixed​

  • POST /customers/{code}/withdrawals and POST /customers/{code}/deposits — a transfer the exchange rejects due to a business rule violation (e.g. an amount above the available balance) now returns 400 with INSUFFICIENT_FUNDS (or VALIDATION_ERROR) instead of 500 "unexpected exchange error".
  • POST /customers/{code}/withdrawals and POST /customers/{code}/deposits — the amount field is now validated against the documented format and must be strictly positive. Zero-amount transfers were previously accepted (201) and created a meaningless transfer record; they are now rejected with 400 VALIDATION_ERROR.

2026-07-16 — v1.12.1​

Fixed​

  • balance-changes WebSocket channel — mark-to-market movements now carry transaction_type: "settlement", matching the type the same ledger row carries on GET /transactions. They were previously published under the internal name remarking; clients matching on remarking must switch to settlement.

2026-07-13 — v1.12.0​

Added​

  • GET /v1/customers/transactions — broker-scoped transaction ledger across all customers, with an optional customer_code query parameter to scope to one customer. Responses cover all transaction types (deposit, withdrawal, trade, settlement, funding) newest-first with cursor pagination (after/before, populated response_metadata); liquidation/auto-deleveraging fills are reported as plain trade rows and status is limited to pending/completed/cancelled.
  • balance-changes WebSocket channel — transaction_type gains liquidation and auto_deleveraging: forced fills (exchange liquidation engine / auto-deleveraging) are now labeled instead of arriving as plain trade movements. Same message shape as trade (total_amount = realised_pnl - fee).
  • balance-changes WebSocket channel — symbol is now also present on trade-family movements (trade, liquidation, auto_deleveraging), so a movement can be tied to its instrument/position without joining against the trades feed. Forced fills carry no reference_id (there is no client order), making symbol the position reference.

Changed​

  • GET /v1/customers/{code}/transactions is served from the same internal ledger as the new broker-scoped endpoint: identical row semantics, and the previously ignored after/before cursor parameters now paginate.

Deprecated​

  • GET /v1/customers/{code}/transactions — superseded by GET /v1/customers/transactions?customer_code={code}. The endpoint keeps working but will be removed in a future major version.

2026-07-09 — v1.11.0​

Changed​

  • Breaking — GET /v1/customers/{code}/transactions: on trade, liquidation and auto_deleveraging rows, total_amount (and its deprecated duplicate amount) is now the fill's net cash movement (realised_pnl − fee, absolute value, at full precision) — the same quantity the balance-changes WebSocket publishes as total_amount. It was previously the traded notional (price × quantity) rounded to 2 decimals. direction on those rows now carries the sign of the cash movement (previously it encoded the order side: buy = credit, sell = debit).
  • GET /v1/customers/{code}/transactions no longer returns a second trade row per fill sourced from the exchange's collateral journal; each fill appears exactly once.

Added​

  • GET /v1/customers/{code}/transactions — total_amount, the authoritative movement field going forward, named after its balance-changes WebSocket counterpart (signed there; absolute here, with direction carrying the sign). It currently duplicates amount, which is deprecated.
  • GET /v1/customers/{code}/transactions — new fields mirroring the balance-changes WebSocket: realised_pnl and reference_id (the client-supplied order id) on trade-type rows, mark_price on settlement rows, and funding_rate on funding rows.
  • max_leverage on GET /v1/customers/{code}/margin-profile — the maximum leverage a customer may select when placing an order. Orders requesting a higher leverage are rejected with a validation error, as are in-range values with no exact integer-percent initial-margin representation (currently only leverage 11). Currently a platform-wide constant ("13"); per-customer limits are planned.

Deprecated​

  • amount on transaction rows — replaced by total_amount (currently an exact duplicate); it will be removed in an upcoming release. Migrate to total_amount.
  • max_leverage on GET /v1/instruments rows — never populated (always an empty string); it will be removed in an upcoming release. Use max_leverage on GET /v1/customers/{code}/margin-profile instead, which carries the leverage cap enforced at order entry.

2026-07-06 — v1.10.0​

Added​

  • PUT /v1/customers/{code}/fee-profile — set a customer's fee schedule across all instruments in one request. Accepts the same maker_fee and taker_fee body as the per-instrument PUT /v1/customers/{code}/fee-profile/{symbol} endpoint (both in basis points) and returns the customer's full FeeProfileList with the updated schedule for every instrument.

2026-06-17 — v1.9.0​

Added​

  • WebSocket balance-changes — real-time balance ledger movements, the push counterpart of GET /v1/customers/{code}/transactions. Private, broker-scoped channel: an authenticated connection receives movements for every customer under its broker. Each message's code equals the matching /transactions row's code (and the /trades/trades WS code for trade and trade-fee movements), so a balance change can be joined back to its ledger entry. balance and balance_as_of carry the resulting end balance and are present only on completed events. Subscribe with {"op": "subscribe", "args": ["balance-changes"]}.

2026-06-15 — v1.8.0​

Changed​

  • Breaking — the order status enum was reworked on both the REST order schema and the WebSocket orders channel:
    • Added partially_filled — an order that has been partially executed and is still resting on the book. Such orders previously reported open.
    • Removed canceled_partially_filled — an order canceled after a partial execution now reports canceled. Inspect filled_amount (and filled_quote) to tell whether any quantity filled before the cancellation.

2026-05-25 — v1.7.0​

Added​

  • cash_amount on order entry (POST /v1/customers/{customer_code}/orders) — place market and limit orders by notional value in the quote currency instead of contract size. Mutually exclusive with amount (exactly one is required for market and limit orders), must be a positive number, and requires time_in_force: IOC (the default when omitted; FOK and GTC are rejected). Not supported for stop/take-profit order types. The notional is resolved into a contract quantity and filled immediately.
  • cash_amount and filled_quote on order responses — both the REST order schema and the WebSocket orders channel now echo the requested notional (cash_amount, present only for cash orders) and report the cumulative filled notional (filled_quote).
  • PUT /v1/customers/{code}/fee-profile/{symbol} — set a customer's per-instrument fee schedule. Accepts maker_fee and taker_fee in the request body and returns the updated FeeProfileItem for the symbol.

Changed​

  • amount is no longer required on order entry — supply cash_amount instead for market/limit orders. It remains required for all other order types.
  • FeeProfileItem.maker_fee and taker_fee (returned by GET /v1/customers/{code}/fee-profile) are documented as basis points (e.g. "2" = 0.02%). The previous "decimal fraction" wording and the "0.0002"/"0.0005" examples were inaccurate; the underlying values have always been bps. Behaviour is unchanged.

2026-05-11 — v1.6.0​

Added​

  • WebSocket orderbook-stream:{symbol} — multi-level orderbook snapshot followed by atomic update batches. Each update message carries one or more changes ({action: new|change|delete, type: bid|ask, price, amount}) that should be applied together. amount is "0" on delete. Public channel, no authentication required.
  • WebSocket market-trades:{symbol} — real-time anonymous trade tape. One envelope per trade. Field set mirrors the REST PublicTrade schema returned by GET /v1/market-trades, so the same parser can be used for both. Public channel, no authentication required.
  • WebSocket error codes: ORDERBOOK_STREAM_UPSTREAM_ERROR, ORDERBOOK_STREAM_UPSTREAM_REJECT, MARKET_TRADES_UPSTREAM_ERROR, MARKET_TRADES_UPSTREAM_REJECT. Channel-scoped — only the affected subscription is torn down, not the whole client connection. Clients should re-issue subscribe to recover.

Changed​

  • WebSocket documentation reorganised into three sections in the sidebar: Connection, Public channels, and Private channels.

2026-05-05 — v1.5.0​

Breaking changes​

  • Removed GET /v1/instruments/{symbol}. Use GET /v1/instruments?symbol={symbol} instead — it returns the same instrument inside a single-record list (or an empty list / 400 for unknown symbols, mirroring the /v1/tickers filter semantics).
  • Removed GET /v1/instruments/{symbol}/leverage_brackets. The single-tier brackets it returned were derivable from the init_margin_req, maint_margin_req, and max_leverage fields already present on each instrument record from GET /v1/instruments.
  • Instrument.status enum changed: removed settled; added post_only (limit orders only, matching disabled) and trade_halt (new orders rejected). The same enum applies to the status query filter on /v1/instruments.

Added​

  • symbol query parameter on /v1/instruments. Supports the same pipe-separated literal and * wildcard syntax as /v1/tickers.

2026-05-04 — v1.4.0​

Breaking changes​

  • Removed GET /v1/customers/{code}/margin-requirements/{symbol} — subsumed by the extended margin-profile response (see Added below).

Added​

  • Optional leverage field on POST /v1/customers/{code}/orders — positive integer (^[1-9][0-9]*$) in [1, 13]. The broker translates it to a per-instrument initial-margin override on the subaccount before placing the order. The override persists across subsequent orders on the same instrument until a different leverage is supplied.
  • instrument_margins array on the MarginProfile response (GET /v1/customers/{code}/margin-profile) — one entry per instrument with a non-default initial margin, each carrying symbol, leverage, and initial_margin.

Changed​

  • Margin / IM string fields (MarginProfile.initial_margin / maintenance_margin, MarginProfile.instrument_margins[].initial_margin, Instrument.init_margin_req / maint_margin_req, LeverageBracket.init_margin_req / maint_margin_req) are now formatted with 2-decimal precision (e.g. "0.12") instead of 6-decimal ("0.120000"). Numerically equivalent — clients parsing as decimal are unaffected.

2026-04-29 — v1.3.0​

Added​

  • Wildcard support in symbol, underlying, and quote_currency filters on /v1/tickers and /v1/instruments — values may use * (matches any sequence of characters, including empty). Matching is case-insensitive and anchored to the full string. Existing exact and pipe-separated values continue to work.

2026-04-09 — v1.2.0​

Breaking changes​

  • Removed stop_price field from all order schemas — replaced by trigger_price, stop_loss_price, take_profit_price, and trigger_price_type
  • Removed stop_price from amend order request
  • stop_loss and take_profit order types now use trigger_price instead of the removed stop_price

Added​

  • New order types: stop_loss_limit, take_profit_limit, take_profit_stop_loss
  • trigger_price field — trigger price for stop_loss, stop_loss_limit, take_profit, take_profit_limit orders
  • stop_loss_price field — stop-loss price for take_profit_stop_loss combo orders
  • take_profit_price field — take-profit price for take_profit_stop_loss combo orders
  • trigger_price_type field — trade_price (for stop/TP types) or mark_price (for combo type)
  • Mechanical types stop_market and stop_limit in order responses and WebSocket updates
  • Advanced orders now included in list open orders response
  • Server-side validation of required fields and allowed trigger price types per order type

Fixed​

  • WebSocket orders and trades topics no longer require a symbol suffix — aligned implementation with documented per-account behavior

2026-04-03 — v1.1.0​

Breaking changes​

  • All enum values are now snake_case (e.g. MarginCall → margin_call, StopLoss → stop_loss, Buy → buy)
  • Renamed /customers/{code}/leverage to /customers/{code}/margin-profile
  • Removed /customers/{code}/risk-limits endpoint
  • Removed realised_pnl from account summary response
  • Removed expiry field and Future/Option from instrument types
  • Removed type query parameter from /instruments
  • Transaction types changed: removed funding_payment, realised_pnl, adjustment; added settlement, funding, auto_deleveraging

Added​

  • type field on customer trades (trade, liquidation, auto_deleveraging)
  • initial_margin and maintenance_margin fields on margin profile
  • settlement and funding transaction types from collateral adjustments
  • before pagination parameter for historical trades

Fixed​

  • Historical trades now default to sort=asc and validate required from/to parameters
  • Currency fields now correctly show USDC instead of USD
  • WebSocket trades topic is now per-account (no symbol suffix required)

2026-03-31 — v1.0.0​

Added​

  • Initial public release