REST API

The complete request/response reference for the Kronos X MTF. Every endpoint below is served on both environments over TLS, returns the same envelope, and is browsable and executable at /docs. Read this page alongside WebSocket: REST is for requests, reference data and history; the socket is for the live event stream.

Base URLs and transport

TLS is mandatory on both environments. Certificates are publicly trusted (Let's Encrypt), so standard system trust stores validate the chain and no certificate pinning is required or supported. Plain HTTP is not exposed at all, so a misconfigured client fails to connect rather than leaking a signed request in clear text.

Interactive reference

/docs on either host. Paste a key and secret into the bar at the top and the page signs each request in your browser, so "Try it out" works before you have written any signing code.

Machine-readable spec

/openapi.json (OpenAPI 3.1). Generate your client from this rather than transcribing tables by hand.

Content type

application/json on every request with a body. The single exception is GET /v1/reconciliation/end-client-positions?format=csv, which answers text/csv.

Response envelope

Every JSON response, success or failure, uses one shape:

{ "code": 0, "msg": "ok", "data": { }, "asOfSeq": 123456789, "ts": 1785000000000 }

What asOfSeq is for. The engine assigns one strictly monotone sequence number per applied command, venue-wide. Every REST response, every WebSocket frame and every recovery cursor carries a number from that same counter, so you can totally order data taken from different transports. If a REST read of /v1/positions returns asOfSeq: 104870 and a WebSocket position frame carries asOfSeq: 104882, the frame is newer and must win, no matter which arrived at your process first. This is what lets you resync a stale cache without a race.

The two-level success check

code: 0 means the gateway accepted and sequenced your request. It does not mean the order is working. A fully validated order can be rejected by the engine inside an HTTP 200 with code: 0, and the outcome lives in data.status and data.rejectCode:

{
  "code": 0,
  "msg": "ok",
  "data": {
    "orderId": 0, "clOrdId": "a3f1c9d24b7e4f108c6d2e5b", "symbol": "BTC-USD-PERP",
    "side": "BUY", "type": "LIMIT", "tif": "POST_ONLY",
    "price": "65000", "qty": "1", "remainingQty": "0", "reduceOnly": false,
    "clientUid": "CLIENT-A", "status": "REJECTED", "rejectCode": 2005,
    "acceptedTs": 1785000000000
  },
  "asOfSeq": 104873, "ts": 1785000000001
}

Treat the check as two gates in sequence: first envelope.code == 0, then data.status != "REJECTED". A pre-book rejection legitimately carries "orderId": 0 because the rejection happened before an order id was assigned; correlate it by clOrdId, which is always echoed. The other transports put the same verdict where their protocol puts verdicts: the WebSocket order.place ack IS the verdict (success: false, the code, the same payload in data) and FIX answers an ExecutionReport with 150=8, 39=8 and the code in 9010. The difference is deliberate and stable; map all three onto one internal outcome, the code and the order state.

Authentication

Public market data needs no credentials. Every private endpoint requires three headers, plus one optional fourth.

The signing string

signature = hex_lowercase( HMAC_SHA256( secret, timestamp + METHOD + pathWithQuery + body ) )

The four parts are concatenated with no separator, no newline and no host:

• timestamp: the exact string you put in X-TIMESTAMP.
• METHOD: uppercase HTTP method, GET / POST / PUT / DELETE.
• pathWithQuery: path plus query string exactly as transmitted, for example /v1/orders/open?symbol=BTC-USD-PERP. Include the leading slash and the ?. Do not re-encode, re-order or drop parameters after signing.
• body: the raw request body as sent, or the empty string when there is no body. The signature covers the exact body bytes regardless of transfer encoding: chunked and HTTP/2 requests of unknown length are verified against the bytes that arrived, exactly like a Content-Length request, and a body that is not valid UTF-8 is verified as raw bytes. A conformant client sees no difference.

Verified signature vector

Reproduce this exactly before you send a single live request. It is the fastest way to isolate a signer bug from a credential problem.

secret     = test-secret
timestamp  = 1700000000000
method     = GET
path       = /v1/account
body       = (empty)

payload    = 1700000000000GET/v1/account
signature  = 741b61b6d3740ede7864551612095d2fb73b75a4f70534f45e9e207bdd1f321c

Second vector: a comma-bearing query string

A GET whose query carries raw commas (not %2C), no body. Reproducing the hex proves your signer; after it matches, also verify in your library's request tracing that the transmitted query is byte-identical to the form you signed.

secret     = test-secret
timestamp  = 1700000000000
method     = GET
path       = /v1/stream/events?fromSeq=904118&channels=execution,margin,order,wallet&limit=500
body       = (empty)

signature  = 821b87a9ee51c26503856f18c0faa712b093aef4ec387e0ef1ecb1ea550651ac

Signer implementations

import hashlib, hmac, json, time
import requests

BASE   = "https://sandbox.mtf.perpetuals.net"
KEY    = "your-api-key"
SECRET = "your-api-secret"

def signed(method: str, path: str, body: dict | None = None, recv_window: int = 5000):
    # Serialize ONCE. The signed string and the transmitted bytes must be identical.
    payload = json.dumps(body, separators=(",", ":")) if body is not None else ""
    ts = str(int(time.time() * 1000))
    sig = hmac.new(SECRET.encode(), (ts + method + path + payload).encode(),
                   hashlib.sha256).hexdigest()
    headers = {
        "X-API-KEY": KEY,
        "X-TIMESTAMP": ts,
        "X-RECV-WINDOW": str(recv_window),
        "X-SIGNATURE": sig,
        "Content-Type": "application/json",
    }
    r = requests.request(method, BASE + path, headers=headers,
                         data=payload.encode() if payload else None)
    return r.json()

# Self-test against the published vector at startup.
assert hmac.new(b"test-secret", b"1700000000000GET/v1/account",
                hashlib.sha256).hexdigest() == \
    "741b61b6d3740ede7864551612095d2fb73b75a4f70534f45e9e207bdd1f321c"

print(signed("GET", "/v1/account"))

import crypto from "node:crypto";

const BASE   = "https://sandbox.mtf.perpetuals.net";
const KEY    = process.env.KRONOSX_API_KEY;
const SECRET = process.env.KRONOSX_API_SECRET;

export async function signed(method, path, body, recvWindow = 5000) {
  // Serialize ONCE; `payload` is both what we sign and what we send.
  const payload = body === undefined ? "" : JSON.stringify(body);
  const ts = Date.now().toString();
  const sig = crypto.createHmac("sha256", SECRET)
                    .update(ts + method + path + payload)
                    .digest("hex");
  const res = await fetch(BASE + path, {
    method,
    headers: {
      "X-API-KEY": KEY,
      "X-TIMESTAMP": ts,
      "X-RECV-WINDOW": String(recvWindow),
      "X-SIGNATURE": sig,
      "Content-Type": "application/json",
    },
    body: payload === "" ? undefined : payload,
  });
  return res.json();
}

// Self-test against the published vector at startup.
const vector = crypto.createHmac("sha256", "test-secret")
                     .update("1700000000000GET/v1/account").digest("hex");
if (vector !== "741b61b6d3740ede7864551612095d2fb73b75a4f70534f45e9e207bdd1f321c")
  throw new Error("signer does not match the published vector");

using System.Security.Cryptography;
using System.Text;

public sealed class KronosXClient(HttpClient http, string apiKey, string secret)
{
    public static string Sign(string secret, string ts, string method,
                              string pathWithQuery, string body)
    {
        using var mac = new HMACSHA256(Encoding.UTF8.GetBytes(secret));
        byte[] h = mac.ComputeHash(Encoding.UTF8.GetBytes(ts + method + pathWithQuery + body));
        return Convert.ToHexString(h).ToLowerInvariant();
    }

    /// <summary>`body` is the exact JSON string that will be transmitted.</summary>
    public async Task<string> SendAsync(HttpMethod method, string pathWithQuery,
                                        string body = "", int recvWindow = 5000)
    {
        string ts = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds().ToString();
        var req = new HttpRequestMessage(method, pathWithQuery);
        if (body.Length > 0)
            req.Content = new StringContent(body, Encoding.UTF8, "application/json");
        req.Headers.TryAddWithoutValidation("X-API-KEY", apiKey);
        req.Headers.TryAddWithoutValidation("X-TIMESTAMP", ts);
        req.Headers.TryAddWithoutValidation("X-RECV-WINDOW", recvWindow.ToString());
        req.Headers.TryAddWithoutValidation("X-SIGNATURE",
            Sign(secret, ts, method.Method, pathWithQuery, body));
        var res = await http.SendAsync(req);
        return await res.Content.ReadAsStringAsync();
    }
}

// Startup assertion:
// Sign("test-secret", "1700000000000", "GET", "/v1/account", "")
//   == "741b61b6d3740ede7864551612095d2fb73b75a4f70534f45e9e207bdd1f321c"

A signed write is accepted once (revision 3.85)

The venue records the X-API-KEY and X-SIGNATURE of every signed request whose method is not GET, once the signature verifies and before the request runs, and keeps the pair for 60 seconds past its X-TIMESTAMP, the longest window a request can ask for; when a pair leaves the record the node refuses every signed write of the same member stamped at or before it with 1002 request signed before the oldest one this node still records: sign it again with a fresh X-TIMESTAMP, so no pair is admitted twice. The same pair again answers HTTP 401, code 1002, msg request already received: a signed write is accepted once, sign every request (a retry included) with a fresh X-TIMESTAMP, and nothing of it runs or is charged. A captured request therefore cannot be replayed: not an amend that would set a resting order back to an old price, not a quote that would come back with a fresh validity, not a batch whose entries carry no clOrdId. A GET is never recorded, and neither is POST /v1/margin/preview, which only reads.

• Sign every send, a retry included, with a fresh timestamp. All three signers above already do (they read the clock per call). Keep the same clOrdId on the retried request: order entry and, since revision 3.85 from the venue's replay-contract line for that release, RFQ requests and quotes are idempotent on it. Never let an HTTP library resend a signed request on its own.
• Two intentionally identical writes in the same millisecond are one signature: give them different timestamps.
• A node refuses a write stamped before it began to accept writes (its start, or its promotion to leader on a cluster), with 1002 request signed before this node began to accept writes: sign it again with a fresh X-TIMESTAMP: a request held across a restart or a leader change is signed again.

Credential scope

Every credential carries a scope, fixed at issue time by venue operations.

The gate is enforced on every write on every transport, REST, WebSocket and FIX alike, so a drop-copy key cannot become a trading key by changing protocol. Issue READ_ONLY keys to back office, risk, reporting and reconciliation components: it removes an entire class of production accident from processes that have no business sending orders. On POST /v1/orders the scope check runs after the body parse, so a 1005 rejection still echoes your clOrdId and is correlatable from the response body alone.

Rate limits

Two independent token buckets per MEMBER, shared across every API key the member holds (previously documented as per API key; with multi-key credentials, per-key buckets would multiply the budget by the number of keys issued). Order placements, amendments and every entry of a placement or amendment batch consume the order budget; cancels, the entries of a cancellation batch included, are never throttled. Order-budget traffic does not consume a read token, so heavy polling can never throttle your order flow and heavy order flow can never exhaust your read allowance.

A denied batch consumes nothing: if fewer than N units are available, the whole batch answers 1003 with a retryAfterMs covering the full N-unit deficit, and every token you had stays in the bucket. The amendment batch (revision 3.74) is charged after the venue's engine-busy check, so its engine-busy 5001 consumes nothing either; the units of a batch whose entries are refused after the charge (an order not found, a blocked market, a grid refusal) stay spent, and a placement batch refused at the envelope with 5001 or 1004, which come after its charge, has spent its units too.

Both are full-capacity token buckets that refill continuously, so after a quiet period the entire minute's allowance is available at once. That is deliberate: a DMA member must be able to push a burst of risk-reducing orders when many end clients liquidate in the same few seconds, and a smoothed limiter would be exactly wrong at that moment. A breach returns HTTP 429 with code 1003.

Backing off correctly

The buckets are not fixed or sliding windows. Tokens accrue every millisecond, so a drained bucket admits again after one token's worth of time rather than at some window boundary. Every 1003 tells you exactly how long that is:

HTTP/1.1 429 Too Many Requests
Retry-After: 1
X-RateLimit-Retry-After-Ms: 2

{ "code": 1003, "msg": "rate limit exceeded",
  "data": { "clOrdId": "your-ref-9001", "retryAfterMs": 2 },
  "asOfSeq": 0, "ts": 1785000000123 }

The same number rides the WebSocket ack (data.retryAfterMs) and the FIX reject (in Text(58)), so the contract is identical on all three transports.

Cancels consume neither bucket. A member must always be able to withdraw liquidity, so cancellation is never rate limited and never blocked. Cancels do still count as order messages under the RTS 9 order-to-trade regime. Every entry of a placement batch counts, whatever its per-entry outcome; an entry of an amendment or cancellation batch (revision 3.74) counts only when the venue submits it, so a row the venue answers before submitting anything for it (2014, 1004, 2049, a grid refusal, a cancellation naming no open order of yours) counts nothing. The regime measures order messages against trades over a rolling window and blocks new orders, batches and amendments only with code 1004 when a member-specific threshold is exceeded; a placement batch is gated per market as a whole, while an amendment batch (revision 3.74) answers 1004 as the row of each entry on a blocked market and runs its other entries, and counts an entry when the venue hands it to the matching engine. A lower warning threshold flags the member to venue operations without rejecting anything. Limits and thresholds are per environment and can be adjusted per member.

Repeated engine faults (revision 3.79). A command the matching engine aborts on answers 5005 (section 9), and the venue verifies its books after every such abort, which costs every venue node time. When ten of your commands answer 5005 within 60 seconds, every request of yours that consumes the order budget, on every key and channel, answers HTTP 429 with code 1003 and retryAfterMs until the oldest of those ten is 60 seconds old, so the wait can be up to 60,000 ms here. A request refused this way does nothing and consumes no order-budget unit (a barrier early close spends one read unit, see below). A request that consumes no order-budget unit, every cancellation among them, is never refused by it, and no other member is affected. A request that can only reduce your risk passes it too: a reduce-only order (reduceOnly true on POST /v1/orders and the WebSocket order.place, FIX 9001=Y on 35=D), a placement batch (POST /v1/orders/batch, WebSocket orders.batch) whose every entry is reduce-only, a lot close (POST /v1/lots/{lotId}/close) sent with reduceOnly true, and a barrier early close: the holder's close request (POST /v1/rfq with closeContractId), the writer's quote on that close request and the holder's accept of that quote. Such a request still consumes its order-budget unit, and the engine still rejects a reduce-only order that would increase a position. At the budget the venue reads whether such an early close is your own (a close request naming an open contract you hold, a quote on a close request of a contract you wrote, an accept of a quote on a close request of a contract you hold), and that read consumes one unit of your read budget whatever its outcome; any other, another member's contract or close request or one that does not exist, answers 1003, and so does your own while your read budget is empty, because the venue then does not read. While the venue sheds order entry it does not read, and the request answers 5001; it also answers 5001 when the read meets a full engine queue, after the read unit is spent; both are the answers below the budget while order-budget units remain. An amendment, single or batch, is still refused, and so is a placement batch with even one entry that is not reduce-only (the whole batch is refused). A 5005 is a fault of the venue: never resend such a command unchanged, and tell venue operations which command it was. Such a refusal names its cause: msg reads rate limit: repeated engine faults (5005) on REST and in the WebSocket ack, and FIX Text(58) begins with the same words before the wait (every other 1003 keeps its text; both begin with rate limit). When the budget trips, the venue mails your trading contact on file (without one, your incident or compliance contact) once. Ten 5005 answers in 60 seconds is a published rule of the venue: production runs exactly these values on every node.

Reads of the venue's history store (revision 3.73). The event stream routes (GET /v1/stream/events, GET /v1/stream/cursor and its WebSocket twin get.streamCursor, GET /v1/margin/calls) and the history routes GET /v1/executions, GET /v1/orders/history, GET /v1/account/ledger, GET /v1/adl/events and GET /v1/reconciliation/end-client-positions are served from the venue's history store. Beside your read bucket four technical bounds apply to them, on each node of the venue that serves you: how many reads of yours of each of the two groups run at once, a budget of these reads in flight on the node that every member shares, how long one read may run, and a yield to the venue's own writes to the store. The event stream group covers every stream reader of yours, all keys and all filters together: combine your filters into one reader or serialise your readers. A read beyond the in-flight bound or the shared budget waits briefly for its turn, then answers HTTP 429 with 1003 and a SUGGESTED retryAfterMs (a turn of the in-flight bound frees when another read of yours ends, a turn of the shared budget when any member's read on the node ends, never at a token refill: a 1003 while no other read of yours of the group is in flight comes from the shared budget, which serialising cannot help, so sleep the wait and back off if it repeats). A read that exceeded the time bound, a read of a group held after such a read, a read while the store is catching up with the venue, and a read the store could not answer (HTTP 500 with 5000 before this revision) answer HTTP 503 with 5007 and retryAfterMs. Nothing changed on your account, and the read token was spent. Keep one request in flight per stream, set your client timeout to at least 15 seconds, and after repeated 5007 on the same read narrow it (a smaller limit, a later cursor or from, no symbol).

Public endpoints

No signature, no headers, not charged to your key buckets.

Instruments

The reference data every other call depends on. Fetch it at startup, cache it, and drive all rounding from it. Hard-coding tick sizes and quantity steps is the second most common cause of avoidable 2002 rejections, and sandbox and production instrument configurations can differ.

{
  "code": 0, "msg": "ok",
  "data": [
    {
      "symbol": "BTC-USD-PERP", "kind": "PERP", "mode": "ORDER_BOOK",
      "isin": "CH1300000001", "cfi": "FFICSX",
      "baseAsset": "BTC", "quoteAsset": "USD", "settlementCcy": "USD",
      "tickSize": "0.5", "qtyStep": "0.0001", "minQty": "0.0001",
      "minNotional": "5",
      "maxOrderQty": "5000", "maxPositionQty": "50000",
      "maxPositionNotional": "2000000000",
      "maxOrderNotional": "10000000",
      "priceBandBps": 500, "marketMaxSlippageBps": 200,
      "makerFeeRate": "0.0001", "takerFeeRate": "0.0005",
      "fundingIntervalHours": 8,
      "funding": { "schedule": "GRID", "intervalHours": 8, "nextSettlementTs": 1785009600000 },
      "riskTiers": [{ "notionalCap": "max", "imRate": "0.02", "mmRate": "0.01" }],
      "maxLeverage": "50", "leverageMode": "FIXED", "status": "ACTIVE", "tradingHours": "CONTINUOUS"
    },
    {
      "symbol": "SP500-USD-PERP", "kind": "PERP", "mode": "ORDER_BOOK",
      "baseAsset": "SP500", "quoteAsset": "USD", "settlementCcy": "USD",
      "tickSize": "0.1", "qtyStep": "0.001", "minQty": "0.001", "minNotional": "5",
      "makerFeeRate": "0.0002", "takerFeeRate": "0.0005",
      "fundingIntervalHours": 24,
      "funding": { "schedule": "LOCAL_DAILY", "zone": "NEW_YORK", "snapshotLocalTime": "16:00",
                   "vwapWindow": "15:55-16:00", "vwapSnapshots": 5,
                   "nextSettlementTs": 1786464000000, "nextSnapshotTs": 1786464000000 },
      "riskTiers": [{ "notionalCap": "max", "imRate": "0.1", "mmRate": "0.05" }],
      "maxLeverage": "10", "leverageMode": "FIXED", "status": "ACTIVE", "tradingHours": "CONTINUOUS"
    }
  ],
  "asOfSeq": 1041, "ts": 1785000000123
}

Trading hours. Every market on the Platform other than a SECURITY market with an auction schedule (Member API section 6j) trades continuously, 24 hours a day, every calendar day of the year, weekends and public holidays included. There is no daily open, close or auction on those markets. Trading in a market is interrupted only by a suspension, halt or removal under Section 11 of the Rulebook (including a venue-wide suspension), by the circuit breaker under Section 13 of the Rulebook, or by the reduce-only and post-only sessions (the Trading page, Halts and suspensions). The Company operates no daily or weekly closure. The only scheduled interruption is the venue's standard maintenance window, Saturday 02:00 to 06:00 UTC, published as a standing exception to the trading hours; maintenance inside it is announced at least 48 hours in advance on the Website and in the member portal. Most releases are rolling and need no window; a release that needs one keeps the restart contract of section 10.7 of the Member API reference (advisory frame, close 1001, 503 with Retry-After, FIX Logout, cursor backfill). A release that requires the venue to stop is announced on the Website at least five Business Days before the window (Business Day as defined in the Rulebook), naming the date, the start time in UTC and the expected duration. A scheduled closure outside that window is published on the Website in advance with the notice the Rulebook requires for a material amendment; an unplanned stop is a suspension under Section 11 of the Rulebook. The current trading state of each market is published at all times on GET /v1/status, GET /v1/instruments and the venueEvents channel. Funding on perpetual contracts settles on the schedule published per market whether or not the underlying reference market is open. A connection interruption during a software release (the venue restart advisory) is not a closure: orders, positions and contracts persist and the market resumes in the trading state it had. Every instrument row carries tradingHours, CONTINUOUS on every listing without an auction schedule and SCHEDULED on a SECURITY market with one (Member API section 6j); the set is open.

Order book

{
  "code": 0, "msg": "ok",
  "data": {
    "symbol": "BTC-USD-PERP",
    "bids": [["64999.5", "12"], ["64999", "3"]],
    "asks": [["65000", "7"], ["65000.5", "20"]],
    "checksum": 2016409727
  },
  "asOfSeq": 1041, "ts": 1785000000123
}

Rows are [price, qty], both exact decimal strings, best price first. checksum is a CRC32C over the canonical string of the levels this snapshot carried, capped at the top 25 per side (so min(depth, 25)): at depth 1, 5 or 25 it covers exactly the rows you received, and a depth=100 snapshot returns 100 rows but its checksum still covers only the top 25, so verify a snapshot against the rows you hold (at most 25), never against all 100. WebSocket DELTAS are different: their checksum is always the top 25 of the full book, so continuous delta verification needs a subscription depth of 25 or 100. It is computed the same way, byte for byte, as on the WebSocket orderbook channel, so you can validate a locally maintained book against a REST snapshot with a single integer comparison.

Ticker, mark and index

{
  "code": 0, "msg": "ok",
  "data": {
    "symbol": "BTC-USD-PERP", "lastPrice": "65000",
    "bestBid": "64999.5", "bestAsk": "65000.5",
    "markPrice": "65001.25", "indexPrice": "65002",
    "fundingRate": "0.0001", "predictedFundingRate": "0.00012",
    "fundingRatePct": "0.01", "predictedFundingRatePct": "0.012",
    "fundingRateAnnualizedPct": "10.95",
    "nextFundingTs": 1785009600000,
    "openInterest": "18420", "volume24h": "93110"
  },
  "asOfSeq": 1041, "ts": 1785000000123
}

Price fields are omitted when the venue has no value yet (no trade, no sequenced mark). On spot instruments fundingRate, predictedFundingRate, their Pct twins and openInterest are "0" and nextFundingTs is 0: those are perpetual concepts and are zeroed rather than removed, so one parser handles both kinds. The single exception is fundingRateAnnualizedPct, which is OMITTED on a market with no funding grid rather than zeroed, because a fabricated zero would read as a market that genuinely costs nothing to hold.

{ "code": 0, "msg": "ok",
  "data": { "symbol": "BTC-USD-PERP", "markPrice": "65001.25", "srcTs": 1785000000090 },
  "asOfSeq": 1041, "ts": 1785000000123 }

Mark price is what risk uses: margin, liquidation, unrealized PnL and MARK-sourced triggers all read this value, not last trade. srcTs is the source timestamp of the underlying observation in milliseconds, so you can detect a stale feed on your side. GET /v1/index-price?symbol= is the identical shape with an indexPrice field. When no mark exists yet, order entry on that instrument returns 3005, which is deliberately distinct from a halt (3003) and from a delisting (3006).

Funding

{ "code": 0, "msg": "ok",
  "data": { "symbol": "BTC-USD-PERP", "fundingRate": "0.0001",
            "predictedFundingRate": "0.00012",
            "fundingRatePct": "0.01", "predictedFundingRatePct": "0.012",
            "fundingRateAnnualizedPct": "10.95", "fundingIntervalHours": 8,
            "settleCcy": "USD", "nextFundingTs": 1785009600000,
            "funding": { "schedule": "GRID", "intervalHours": 8, "nextSettlementTs": 1785009600000 } },
  "asOfSeq": 1041, "ts": 1785000000123 }

Every perpetual publishes HOW its funding is scheduled in the funding block, here and on GET /v1/instruments (revision 3.42). Two schedules exist today and the set is open:

• GRID (the crypto perpetuals): funding settles at fixed UTC anchors every intervalHours at the rate in force (the published fixedRate on a market whose funding.rateSource is FIXED, else the last sequenced tick rate) and the last sequenced mark; a positive rate means longs pay shorts. Every elapsed anchor settles, so an outage spanning several anchors produces one settlement per missed anchor. Funding never settles on a mark the venue holds as stale (revision 3.70): while the market is in reduce-only for STALE_MARK_PRICE, or its last mark is older than staleMarkTimeoutSec, due anchors wait (nextSettlementTs stays at the waiting anchor) and settle at the first settlement after the market leaves reduce-only, each at the then rate in force and mark on the positions held at that settlement (settleTs the anchor, settledTs the settlement time); the catch-up after a venue outage waits for the mark feed the same way. While a settlement is more than 60 s overdue, orders without reduceOnly (a client-level close sent without the flag included), non-reduce-only amends and RFQ accepts on the market answer 3014 and a triggered opening conditional is canceled FUNDING_CATCH_UP until the catch-up lands (the funding catch-up fence, Trading page). Both dormant on the sandbox until the operator decision batch epoch announced by venue operations, live on production from the first day.
• LOCAL_DAILY (the equity index, gold, oil and FX perpetuals, and since revision 3.75 on the sandbox silver and the USD/JPY quanto): one settlement per calendar day at a local wall-clock window in zone (UTC, LONDON or NEW_YORK; the venue applies daylight saving). At snapshotLocalTime the venue captures every open position and the index (nextSnapshotTs is the next capture); over vwapWindow it records one mark per minute, vwapSnapshots of them at the minute boundaries counted back from the window end; at the window end (nextSettlementTs) it settles rate = clamp((mean of the recorded marks - indexAtSnapshot) / indexAtSnapshot, floor, cap), positive meaning longs pay, applied to the SNAPSHOT positions with the mean as the settle mark, so a position closed after the snapshot still pays that day and one opened after it pays nothing until the next. A day with no snapshot (venue outage) is skipped, never charged later. fundingIntervalHours reads 24 on these markets. Today: FX and gold on London 16:00 (window 15:57 to 16:03, six snapshots; since revision 3.75 silver and the USD/JPY quanto too), WTI on New York 14:30 (14:25 to 14:30, five), Brent on London 19:30 (19:25 to 19:30, five), the equity indices on New York 16:00 (15:55 to 16:00, five); read the live values from the block. Settlement runs every calendar day, including days on which the underlying market is closed: the venue mark and index then carry the last available values of the venue's reference price source and the rate is bounded by funding.rateCap and funding.rateFloor.

On a LOCAL_DAILY market predictedFundingRate, predictedFundingRatePct and predictedFundingPerUnit (here, on GET /v1/ticker and on the WebSocket funding rate frame) are the rate the marks recorded so far would settle at, and they are OMITTED, not null and never a fabricated zero, before the day's window opens.

GET /v1/funding/history?symbol=&from=&to=&limit= returns settled rates as {settleTs, settledTs, fundingRate, fundingRatePct, fundingRateAnnualizedPct, fundingPerUnit, markPrice, settleCcy} rows; settleTs is the anchor settled and settledTs (revision 3.70) the time of the settlement command, equal to settleTs plus the timer latency in steady state and later than it for an anchor settled after a stale-mark deferral or a venue outage, omitted on rows recorded before that revision; LOCAL_DAILY rows additionally carry settlementValue (the mean the day settled at), indexAtSnapshot, snapshotsUsed and snapshotTs. Since revision 3.70 includeSkips=true interleaves, newest first, the LOCAL_DAILY days that closed WITHOUT a settlement as rows shaped {settleTs, skipped: true, skipReason, snapshotTs, settleCcy}, skipReason NO_POSITION_SNAPSHOT (no position snapshot was held when the window closed, for example after an outage across the snapshot time) or NO_MARK_SNAPSHOTS (no mark inside the VWAP window), an open set; no funding is exchanged for such a day and none is charged later. The default list is byte-identical to before (never a skipped field on a settled row); a value that is not a boolean answers 400.

The currency-denominated figure is the payment, booked in the instrument's settlement currency. Read what a position has actually paid from accFunding on GET /v1/positions or GET /v1/positions/end-clients, and the cash movements from GET /v1/account/ledger?kind=FUNDINGPAY and FUNDINGRECEIVE. Settlement currency is a property of the instrument rather than of the venue, so every surface carrying a funding amount also carries settleCcy. Today every listed market settles in USD; do not hard-code that.

Venue and instrument status

{
  "code": 0, "msg": "ok",
  "data": {
    "venue": "ACTIVE", "venueTradingState": "TRADING", "venueSince": 1784900000000,
    "instruments": [
      { "symbol": "BTC-USD-PERP", "status": "ACTIVE", "tradingState": "TRADING" },
      { "symbol": "ETH-USD-PERP", "status": "HALTED", "tradingState": "HALTED",
        "reason": "CIRCUIT_BREAKER", "since": 1785000012000,
        "expectedResumeTs": 1785000042000 }
    ],
    "seqNo": 1041
  },
  "asOfSeq": 1041, "ts": 1785000000123
}

The legacy venue and status fields keep their original spellings byte for byte. The additive venueTradingState, tradingState, reason, since and expectedResumeTs use the same vocabulary as the WebSocket venueEvents channel: tradingState is one of TRADING, HALTED, REDUCE_ONLY, POST_ONLY, DELISTED, and reason is one of CIRCUIT_BREAKER, STALE_MARK_PRICE, DELISTING, ADMINISTRATIVE. reason, since and expectedResumeTs are omitted when they do not apply, which is why the first instrument above has three fewer keys than the second.

Other public routes

Trading endpoints

Place order

{
  "symbol": "BTC-USD-PERP",
  "side": "BUY",
  "type": "LIMIT",
  "tif": "GTC",
  "price": "65000",
  "qty": "1",
  "reduceOnly": false,
  "clOrdId": "a3f1c9d24b7e4f108c6d2e5b",
  "clientUid": "CLIENT-A",
  "leverage": 50,
  "quoteCcy": "USD"
}

The leverage assertion. The venue margins your member account on the instrument tier schedule and does not model per-end-client leverage at all. The field is validated and then echoed; it never changes the margin applied. It holds only when the instrument runs a single open-ended risk tier whose effective initial margin, that is the tier rate multiplied by your member IM multiplier, is exactly 1 / leverage as an exact integer identity. Two consequences worth building for: on a TIERED instrument every whole-number leverage assertion is false and returns 2018, because effective leverage is size-dependent; and the check is member-aware, so if the venue runs your account at a stricter profile your effective leverage is maxLeverage / imMultiplier (read imMultiplier from GET /v1/account) and that is what the assertion is compared against. If you offer clients a fixed leverage, enforce it on your side before submitting.

Response. The synchronous outcome: final status plus any executions produced while matching. status is one of NEW, PARTIALLY_FILLED, FILLED, CANCELED, EXPIRED, REJECTED, PENDING_TRIGGER. A conditional order that has not yet triggered reports PENDING_TRIGGER on the ack and on every surface (WS order frames, live reads, the event stream) until it triggers, at which point it becomes NEW.

{
  "code": 0, "msg": "ok",
  "data": {
    "orderId": 887711, "clOrdId": "a3f1c9d24b7e4f108c6d2e5b",
    "symbol": "BTC-USD-PERP", "side": "BUY", "type": "LIMIT", "tif": "GTC",
    "price": "65000", "qty": "1", "remainingQty": "0", "reduceOnly": false,
    "clientUid": "CLIENT-A", "status": "FILLED",
    "executions": [
      { "tradeId": 55123, "orderId": 887711, "symbol": "BTC-USD-PERP", "side": "BUY",
        "price": "65000", "qty": "1", "fee": "32.5", "role": "TAKER",
        "flags": "NORMAL", "clOrdId": "a3f1c9d24b7e4f108c6d2e5b",
        "refSource": "MEMBER", "clientUid": "CLIENT-A", "ts": 1785000000118 }
    ],
    "acceptedTs": 1785000000117,
    "leverage": 50,
    "quoteCcy": "USD"
  },
  "asOfSeq": 104873, "ts": 1785000000119
}

Queue position on the ack. When a placement RESTS an order on the book, the ack carries two additional fields: queueQtyAhead, a decimal quantity string, the quantity resting ahead of your order at its price level in FIFO priority, and queueOrdersAhead, an integer, the number of orders ahead of it at that level. The fields are PRESENT exactly when the placement left the order resting: a GTC or GTD limit that rested in full, the resting remainder of a partial fill, a post-only rest. A first order at an empty level reports "0" and 0, present, meaning front of the queue. The fields are ABSENT, not null, wherever no queue position exists: full fills, the canceled remainder of an IOC, FOK or market order, conditionals accepted as PENDING_TRIGGER, rejections, amend responses and order-history reads. Presence means resting AT ACK TIME: when the same command that placed the order also terminates it after the rest, for example a stop released by the placement's own prints crosses into the just-rested remainder, the ack reports the terminal status and the queue fields are cleared. The figures are a snapshot taken at the moment the order rested, measured after any reduce-only trim the same placement caused, and they are immediately stale: the venue never updates them on the order. For a live picture, watch the book channels. The same two fields ride the WS order.place ack and the ORDER_ACCEPTED frame of the private order channel, and on FIX the accept ExecutionReport carries them as venue tags 9017 and 9018 (see the FIX page).

Rejection ordering inside the gateway is fixed and worth knowing when you interpret a failure: authentication, then body parse (2017), then the reserved KX- prefix (2020), then credential scope (1005), then the order-message bucket (1003), then the RTS 9 regime (1004), then field validation (2001, 2021, 2018, 2002, 2004, 2013), then the engine itself (2003, 2005 to 2012, 2015, 2016, 2022, 2028, 3001 to 3006).

Hedge mode (positionSide)

By default the venue keeps ONE netted sub-position per (clientUid, instrument): opposite flow for the same client nets, so a client cannot be long and short the same perpetual at once. The optional positionSide field lifts that, per order, without a second clientUid. Tagging an order LONG or SHORT routes its fills to that bucket of the client's sub-position: a client can hold at most three sub-positions per instrument, one LONG bucket, one SHORT bucket and the netting bucket every untagged order acts on. Netting still applies inside a bucket, so a BUY tagged SHORT reduces the short bucket (and extends through zero, flipping inside the bucket, exactly as netting always did), and tagged and untagged flow never touch each other's buckets. The same field and semantics apply on the WS order.place op, on every batch entry and on FIX (venue tag 9016, see the FIX page).

Worked example. Your client HEDGE-1 buys 0.5 BTC-USD-PERP tagged LONG, then sells 0.3 tagged SHORT. The venue now holds two sub-positions for the client, LONG +0.5 and SHORT -0.3, and your member position moved by the net +0.2, exactly as it would have moved without the field. A later BUY of 0.1 tagged SHORT reduces the short bucket to -0.2. An order without positionSide keeps acting on the client's netting sub-position, which the tagged flow never touched.

GET /v1/positions/end-clients (and the WS clientPosition channel and get.clientPositions op) report each bucket as its own row: rows carry positionSide ("LONG" | "SHORT"), omitted on netting rows, so a client using hedge mode can show up to three rows per instrument. Acks, open-order reads and order events echo positionSide back, OMITTED (not null) for netting orders, so every pre-hedge payload stays byte-identical.

Batch order entry

One signed message, 1 to 50 complete, independent orders. Every entry is a full place-order body with its own clOrdId and its own clientUid; that is the point of the feature: one message, N client-tagged orders, for example one close per end client when you unwind a book. Each entry passes exactly the validation a single POST /v1/orders passes, including the minNotional floor with its reduce-only exemption, the order-size and position caps exactly as they apply to singles (2013 and 2011: each entry is one message against the order-size cap, and an earlier entry's working remainder counts in a later entry's worst case), strict unknown-field rejection (2017) and the reserved KX- namespace guard (2020). The worked example below is the mass-close use case: one message unwinds three end clients' long positions with three reduceOnly sells, each entry tagged with the client it closes, against a member book that is itself net long. The warning under the example explains why that last qualifier is load-bearing.

{
  "orders": [
    { "symbol": "BTC-USD-PERP", "side": "SELL", "type": "LIMIT", "tif": "GTC",
      "price": "65000", "qty": "0.2", "reduceOnly": true,
      "clOrdId": "close-cl-a-1", "clientUid": "CLIENT-A" },
    { "symbol": "BTC-USD-PERP", "side": "SELL", "type": "LIMIT", "tif": "GTC",
      "price": "65000", "qty": "0.5", "reduceOnly": true,
      "clOrdId": "close-cl-b-1", "clientUid": "CLIENT-B" },
    { "symbol": "BTC-USD-PERP", "side": "SELL", "type": "LIMIT", "tif": "GTC",
      "price": "65000", "qty": "0.1", "reduceOnly": true,
      "clOrdId": "close-cl-c-1", "clientUid": "CLIENT-C" }
  ]
}

Non-atomic by design. The batch is a transport optimisation, not a transaction: each entry validates and executes independently, one entry's rejection never affects its neighbours, and there is no all-or-nothing execution mode. Entries are submitted to the matching engine in array order, and array order is the engine sequencing order among your entries (two crossing entries behave deterministically: the earlier rests, the later matches it). Other members' traffic may interleave between your entries.

The response is HTTP 200 with envelope code 0 and data.results, one entry per order in array order, even when every entry failed. A successful entry has exactly the shape of the single-order place response data (engine-level rejects such as 2028, an order-size cap 2013 or a position cap 2011 ride it as rejectCode with status REJECTED); a failure entry is {"code", "msg", "clOrdId"}: a gateway refusal (strict fields and wrong-typed values 2017, 2020, 2002 and so on; an entry's member names are case-sensitive, where the single POST /v1/orders body is not), the matching engine's 2009 for a reused clOrdId with a different payload, 5001 for an entry the venue did not accept (after an entry the venue's intake refused as it was submitted, every later entry answers 5001 "not submitted"; on a clustered deployment the replicated intake can also refuse an entry after the later ones were submitted, and those may take effect, so read every row) and, since revision 3.74, 5000 for an entry whose outcome the venue could not confirm: reconcile that row by its clOrdId and resend it only with the SAME clOrdId. Before revision 3.74 such a fault answered the whole request with an undocumented HTTP 500. Envelope-level errors are limited to authentication, credential scope (1005), throttle (1003), a malformed body or an entry count outside 1 to 50 (2002 with a descriptive msg), the engine-busy shed (5001), the RTS 9 block (1004) and 5030 on a clustered deployment's follower node; the 5001 and the 1004 come after the charge, so the N units stay spent.

For the worked example above, with 0.2 resting on the bid at 65000, array order means the first entry takes that bid and fills while the second and third rest working:

{
  "code": 0, "msg": "ok",
  "data": {
    "results": [
      { "orderId": 887731, "clOrdId": "close-cl-a-1", "symbol": "BTC-USD-PERP",
        "side": "SELL", "type": "LIMIT", "tif": "GTC", "price": "65000",
        "qty": "0.2", "remainingQty": "0", "reduceOnly": true,
        "clientUid": "CLIENT-A", "status": "FILLED",
        "executions": [
          { "tradeId": 55131, "orderId": 887731, "symbol": "BTC-USD-PERP",
            "side": "SELL", "price": "65000", "qty": "0.2", "fee": "6.5",
            "role": "TAKER", "flags": "NORMAL", "clOrdId": "close-cl-a-1",
            "refSource": "MEMBER", "clientUid": "CLIENT-A",
            "ts": 1785000000117 } ],
        "acceptedTs": 1785000000117 },
      { "orderId": 887732, "clOrdId": "close-cl-b-1", "symbol": "BTC-USD-PERP",
        "side": "SELL", "type": "LIMIT", "tif": "GTC", "price": "65000",
        "qty": "0.5", "remainingQty": "0.5", "reduceOnly": true,
        "clientUid": "CLIENT-B", "status": "NEW", "acceptedTs": 1785000000117 },
      { "orderId": 887733, "clOrdId": "close-cl-c-1", "symbol": "BTC-USD-PERP",
        "side": "SELL", "type": "LIMIT", "tif": "GTC", "price": "65000",
        "qty": "0.1", "remainingQty": "0.1", "reduceOnly": true,
        "clientUid": "CLIENT-C", "status": "NEW", "acceptedTs": 1785000000117 }
    ]
  },
  "asOfSeq": 104874, "ts": 1785000000119
}

Had one entry failed gateway validation instead, only that row would change, for example {"code": 2002, "msg": "price not on the tick grid, or qty not an exact multiple of qtyStep", "clOrdId": "close-cl-c-1"}; its neighbours stand, and you resend only the corrected entry.

Rate limits. A batch consumes one order-budget unit per entry, charged up front, all or nothing: a denied batch answers 1003 with retryAfterMs and consumes nothing. Every entry counts as one order message under the RTS 9 regime, whatever its per-entry outcome. The identical operation is available on the private WebSocket as op orders.batch; it is not offered over FIX, and FIX members submit singles instead.

Batch amendment and batch cancellation

Revision 3.74. Two more routes carry 1 to 50 entries in one signed message, for a market maker that requotes many levels: the amendment batch amends and the cancellation batch cancels orders you already have. Every entry the venue submits reaches the matching engine as the ORDINARY single route: an amendment entry exactly as PUT /v1/orders/{orderId}, a cancellation entry exactly as DELETE /v1/orders/{orderId}. The WebSocket twins are orders.batchAmend and orders.batchCancel; neither route is offered over FIX.

POST /v1/orders/batch/amend
{ "amends": [
    { "orderId": 887731, "qty": "0.15" },
    { "orderId": 887732, "price": "64990.5" },
    { "orderId": 887733, "price": "65010", "qty": "0.2" } ] }

POST /v1/orders/batch/cancel
{ "cancels": [
    { "orderId": 887734 },
    { "clOrdId": "q-ask-3" } ] }

The entries. The body carries exactly one member, amends or cancels (anything else is 2002 for the whole message). An amendment entry is {orderId, price?, qty?}: qty is the new TOTAL quantity, fills included; a quantity decrease at the same price keeps queue priority, any price change or quantity increase is cancel plus new, and every engine check of the single amendment applies at the current state, also to an order that already stands at the requested terms. An amendment names its order by orderId only. A cancellation entry is {"orderId": ...} or {"clOrdId": ...}, exactly one; a clOrdId is compared character for character and never refused for padding. Entry member names are case-sensitive and a value of the wrong JSON type answers 2017 "malformed request body"; 2013 answers an entry that is not an object, an orderId absent or below 1, a cancellation entry with both identifiers or neither and an empty clOrdId. An order named by two entries: the first runs, every later entry naming it answers 2013 "order N is already named by entry k of this batch" (k counted from 0) and nothing is submitted for it.

Non-atomic by design. Entries reach the matching engine in array order, other members' traffic may interleave, and a refused entry never stops a later one: every entry is submitted before the first verdict. Send an entry that depends on another's outcome in a SECOND message after you read the first message's rows. An amendment that reprices re-matches as a taker outside a call auction, so when you shift a two-sided quote amend the side moving away from the other first (in a shift up the asks before the bids) and size down before you size up; the advice holds only when every earlier entry takes effect. Under a margin shortfall, a reduce-only session, a band move or the funding catch-up fence a size-down amendment is refused like any other, so de-risk with the cancellation batch.

The response. HTTP 200, envelope code 0, data.results one row per entry in array order, and asOfSeq, even when every entry failed. A row carrying code is a failure row, {"code", "msg", "orderId", "clOrdId"} echoing only what the entry carried (orderId as a JSON integer of at least 1, or the order a reference resolved to; clOrdId as a JSON string). Any other row is the order: for an amendment its state as of asOfSeq, the PUT data (when the venue could not read your orders back after the batch, which is rare, the order's last state change among the batch's own entries as the order channel renders it, and asOfSeq the lowest seqNo at which a still-working row was taken, or the seqNo before it when the command that made that row's change also traded the order, the row then being the order before those fills: every row is then the order as of asOfSeq or later, and the order and execution events after it bring it up to date), which can read REJECTED (2005, a post-only order repriced to cross; 2015 under REJECT_TAKER) or CANCELED (STP_CANCEL): that level is gone, place it again with a placement batch. For a cancellation the cancelled order, the single cancel's data. rejectCode 5005 on an order row means the entry took effect before a contained fault: reconcile, never resend it as it was.

{ "code": 0, "msg": "ok",
  "data": { "results": [
    { "orderId": 887731, "clOrdId": "q-bid-1", "symbol": "BTC-USD-PERP", "side": "BUY",
      "type": "LIMIT", "tif": "GTC", "price": "64995", "qty": "0.15", "remainingQty": "0.15",
      "reduceOnly": false, "clientUid": "H1", "status": "NEW", "acceptedTs": 1785000000000 },
    { "code": 2014, "msg": "order not found", "orderId": 887732 },
    { "orderId": 887733, "clOrdId": "q-bid-3", "symbol": "BTC-USD-PERP", "side": "BUY",
      "type": "LIMIT", "tif": "POST_ONLY", "price": "65010", "qty": "0.2", "remainingQty": "0.2",
      "reduceOnly": false, "clientUid": "H1", "status": "REJECTED", "rejectCode": 2005,
      "acceptedTs": 1785000000118 } ] },
  "asOfSeq": 104880, "ts": 1785000000121 }

Cancellations are looked up first, and free. The venue resolves every cancellation entry to an OPEN order of yours in one read; an entry naming nothing (not found, not yours, terminal, or a reference naming no open order) answers 2014 and nothing is submitted for it. A cancellation entry is never refused by a halt, a suspension, a risk state, a session measure or a DLT freeze. No order-budget unit, never throttled, never blocked by the RTS 9 regime; each submitted entry counts one order message on your account-wide ratio and each cancelled order one on its market. One cancellation batch of yours is processed at a time on a venue node, a later one waits for it; 5001 when eight already wait. A WebSocket session processes one message at a time, so keep a second private socket for urgent cancels.

Amendments are charged. One order-budget unit per entry, charged up front, all or nothing, after the venue's engine-busy check (1003 and an engine-busy 5001 consume nothing); the units of entries refused afterwards (2014, 1004, 2049, a grid refusal) stay spent. An entry on a market where the RTS 9 regime blocks you answers a 1004 row and the other entries run; an entry counts one order message when the venue hands it to the matching engine. Send only the levels that changed: a no-op entry costs a unit and an order message like any other.

Envelope errors and unsettled rows. The envelope refuses only before anything is submitted: 1001, 1005, 2002, 5001 (the shed, the orders could not be looked up, or your cancellation queue is full), 5030 with the leader on a clustered deployment's follower node, and for the amendment batch 2034 (production) and 1003. After the first submission every outcome is a row: 5001 for an entry the venue did not accept (after an entry the intake refused as it was submitted, every later entry answers 5001 "not submitted", so the accepted entries are the first ones of your array; on a clustered deployment the replicated intake can instead refuse an entry after the later ones were submitted, which then answer their own outcomes and may have taken effect, and that entry counts as an order message like every entry handed over: read every row, never infer the rest from the first 5001), 5000 "outcome unknown" for an entry whose outcome it could not confirm (read the order back on the leader before sending it again), 5005 when a contained fault left nothing in effect. A refused RESEND of an amendment does not mean the first attempt failed: read GET /v1/orders/open before acting.

Trader ID and Authorised Users

Venue operations register the Authorised Users of each member and issue each one a Trader ID of the form TR-{memberId}-{8 hex characters}, for example TR-12-9F3A21BC. The Trader ID of the person entering the order rides reg.traderId.

Enforcement is staged per member. While your member has no registered Authorised Users you are not gated at all, so an existing integration that never sends reg keeps working unchanged. From the moment your first Authorised User is registered, every order must carry a registered, active reg.traderId. One that is absent, unknown or deactivated is rejected with code 2021, HTTP 400, "reg.traderId missing or not a registered Authorised User". It is deterministic: fix the value, do not retry.

Order entry runs through one code path shared by all three transports, so REST, WebSocket and FIX reject identically and a gated member cannot route around the check by changing protocol. On FIX the Trader ID rides venue tag 9012 on NewOrderSingle. The member web portal's RFQ functions apply the same check (Member API 3.70). POST /v1/margin/preview is never gated, because a preview is a read rather than an order entry, which keeps risk tooling working for a gated member.

Cancel and amend

Cancel by venue order id. Returns the cancelled order, rendered from the cancel event: status CANCELED, cancelReason USER_REQUESTED, acceptedTs the cancel's time. 2014 if the id is unknown or belongs to another member; the two cases are deliberately indistinguishable so an id probe leaks nothing. An empty id, DELETE /v1/orders/ with a trailing slash (what a path built from this template becomes when the id is empty), answers HTTP 400 5003 naming the empty orderId and cancels nothing, with or without a query (Member API revision 3.84); before, that path was the cancel of every open order of the route below.

Cancel by your own reference, resolved against your member's active reference index. 2014 when no working order carries that reference. This is the reconciliation tool of choice after a timeout: it is safe to call, it is idempotent in effect, and it tells you whether the order existed. Send clOrdId alone: since Member API revision 3.84 a symbol or side beside it is refused 5003 and nothing is cancelled.

Cancel all your working orders, optionally narrowed by symbol and/or side (BUY or SELL, in any case). Both filters are optional; without either the cancel covers every open order you have on every market, untriggered conditionals included, and an unknown or empty symbol gives 2001. Since revision 3.74 this route and the cancel by clOrdId count one order message on your account-wide order-to-trade ratio, as every other cancel already did (that ratio never blocks). Returns a count, not a list:

{ "code": 0, "msg": "ok", "data": { "canceled": 37 }, "asOfSeq": 104901, "ts": 1785000000500 }

Amend price and/or quantity. The body accepts exactly two optional fields and is strict about everything else:

{ "price": "64950", "qty": "2" }

A quantity decrease at an unchanged price keeps queue priority. Any price change or quantity increase is processed as cancel plus new: fresh priority, re-matched immediately. Margin, price band and position limits are re-checked. Outside a call auction the re-match treats the repriced order as a new one: a post-only order that would cross is rejected 2005 and removed, exactly like a post-only order that would cross at entry, and an order that meets your own resting order with the same clientUid follows your self-trade policy (REJECT_TAKER rejects the amended order 2015, or cancels it STP_CANCEL when part filled; CANCEL_TAKER and CANCEL_BOTH cancel it STP_CANCEL; the default CANCEL_RESTING cancels your resting order instead), while your own order with a different clientUid trades under the default end-client scope. These outcomes answer inside HTTP 200 with the order's status REJECTED or CANCELED (revision 3.74 corrects this paragraph, which said nothing of them); during a call auction, or while the market is closed, the repriced order rests for the uncross. Every other refusal leaves the original order untouched. The response is the order read just after the amendment (the open order, else its terminal record), so it can already carry a later fill, while the envelope asOfSeq is the amendment's own sequence number (revision 3.83 states it). An amendment consumes one order-budget unit exactly like a placement or a batch entry and is subject to the RTS 9 block; cancels are never throttled.

Order state

acceptedTs per surface (revision 3.83, documentation only: nothing changed). The field names a different instant on different surfaces. On every WebSocket order frame and its rows of the event stream, and on every answer rendered from an order event (the DELETE /v1/orders/{orderId} answer, the rows of a cancellation batch, a PUT answer that ended the order, and a read of an order already terminal), it is the venue's sequencing time of that event: the acceptance, the amendment (a venue reduce-only trim included), the cancel, the trigger, the completing fill, the expiry or the rejection; on FIX, TransactTime(60) is the same instant. On the open-order reads, and on GET /v1/orders/{orderId} and the PUT answer while the order is open, it is the placement time, moved to an amendment's time only when an amendment of a working order changes the price or increases the quantity (a size-down, a venue trim, any amendment of an untriggered conditional and a trigger keep it). On GET /v1/orders/history a FILLED, CANCELED or EXPIRED row carries the first acceptance (and closedTs the terminal event), a REJECTED row the rejection time in both; from and to bound acceptedTs.

RFQ trading, barrier contracts and yield contracts

Every instrument on GET /v1/instruments carries a mode: ORDER_BOOK or RFQ. An RFQ market has no order book at all. Order entry there is rejected with code 2022, and trading runs as a request-for-quote negotiation instead: a requester opens an RFQ, other members quote it, and the requester accepts exactly one quote. The routes below are the whole surface. Opening an RFQ on an order-book market is rejected with code 2023, so the two trading styles cannot be confused by accident in either direction. Read the mode from reference data and route accordingly.

Five instrument kinds trade this way. On a PERP market an accepted quote is an off-book perpetual trade, margined and netted exactly like a book fill. On a SPOT market it is prefunded delivery at the quoted price. On a SECURITY market (Member API revision 3.66) it is prefunded delivery exactly like spot, settled on the Kronos X chain (the DLT Market section below). On a BARRIER market it opens a knock-out contract, documented in its own section below; barrier markets are always RFQ. On a SWAP market (revision 3.51) the same verbs run the other way round: POST /v1/rfq is the WRITER's standing offer, POST /v1/rfq/{rfqId}/accept with qty and no quoteId is a TAKE by any other member, and quotes do not exist; see "Yield contracts" below.

Anonymity is structural and symmetric. Makers never learn who is requesting, and the requester never learns who quoted: price, size and validity are the negotiation surface, identity is not. Market Segments are enforced throughout: an RFQ is visible and quotable only to members inside the requester's mutual-acceptance set, and eligibility is re-checked at accept. RFQ is served over REST and the private WebSocket channels only; there is no FIX representation of the flow.

Open an RFQ

{
  "symbol": "BTC-USD-KO",
  "side": "BUY",
  "qty": "10",
  "expiresInMs": 60000,
  "barrier": { "level": "60000", "expiryTs": 1785086400000, "takeProfit": "70000" },
  "clOrdId": "rfq-req-0001",
  "clientUid": "CLIENT-A",
  "reg": { "traderId": "TR-12-9F3A21BC" }
}

The body is strict like order entry: an unrecognised field is rejected with 2017 naming the field. A member may hold at most 64 open RFQs at once (2012). Creation also requires a tradable market: 3003 halted, 3006 delisted, 3005 no mark price yet, and 3002 during any reduce-only session, because an RFQ opens new risk and there is no reduce-only RFQ.

A close request (revision 3.44) is the same route with the contract in place of the trade description:

{
  "symbol": "BTC-USD-KO",
  "closeContractId": 41,
  "expiresInMs": 60000,
  "clOrdId": "rfq-close-0001"
}

{
  "code": 0, "msg": "ok",
  "data": {
    "rfqId": 3101, "symbol": "BTC-USD-KO", "kind": "BARRIER",
    "side": "BUY", "qty": "10",
    "expiryTs": 1785000060000, "createdTs": 1785000000000,
    "barrier": "60000", "takeProfit": "70000", "contractExpiryTs": 1785086400000,
    "strictTakeProfit": false, "premium": "45000", "premiumBps": 9000,
    "clOrdId": "rfq-req-0001", "clientUid": "CLIENT-A",
    "quotes": []
  },
  "asOfSeq": 104950, "ts": 1785000000001
}

expiryTs is the end of the quoting window. On a perp or spot RFQ market barrier, takeProfit, contractExpiryTs, strictTakeProfit, premium and premiumBps are absent, per the null-dropping serializer; takeProfit is also absent on a knock-out-only barrier request. On a barrier market (revision 3.45) strictTakeProfit echoes the flag, premiumBps is the premium share the request would open at (10000 - knockOutRebateBps, or strictTakeProfitPremiumBps on a strict request) and premium is the holder's maximum loss valued INDICATIVELY at the current mark, |mark - barrier| x qty x contract value x premiumBps / 10000: the entry is the quoted price, so the contract's premium is fixed only at accept (65000 mark, 60000 barrier, qty 10, 9000 bps in the example). A close request (revision 3.44) additionally carries closeContractId, with side the derived closing side, qty the full contract quantity, the terms the contract's own and premium / premiumBps / strictTakeProfit the contract's frozen values; the member is absent on an ordinary request.

The open board

Every live RFQ you are eligible to quote, requester anonymous. The board is filtered per caller by Market Segments, and your own RFQs never appear on it: those live on /v1/rfq/mine. A close request (closeContractId set, revision 3.44) is on YOUR board only when you WROTE that contract: nobody else ever sees it, because nobody else may quote it. The optional symbol filter gives 2001 when unknown. data is an ARRAY.

{
  "code": 0, "msg": "ok",
  "data": [
    {
      "rfqId": 3101, "symbol": "BTC-USD-KO", "kind": "BARRIER",
      "side": "BUY", "qty": "10",
      "expiryTs": 1785000060000, "createdTs": 1785000000000,
      "barrier": "60000", "takeProfit": "70000", "contractExpiryTs": 1785086400000,
      "capacity": "FOR_CLIENT", "clientTag": "9f3a21bc00d14e77",
      "quoteCount": 2,
      "myQuote": { "quoteId": 8804, "price": "64950",
                   "expiryTs": 1785000042000, "clOrdId": "rfq-mk-77" }
    }
  ],
  "asOfSeq": 104960, "ts": 1785000010000
}

quoteCount is the number of live quotes on the RFQ; myQuote is present only when you have one, with your own reference. No requester identity, no requester reference and no other maker's quote is ever exposed here.

Your RFQs and your quotes

Quote an RFQ

{ "price": "64950", "expiresInMs": 30000, "clOrdId": "rfq-mk-77",
  "clientUid": "HOUSE", "reg": { "traderId": "TR-31-0C44D2AA" } }

One live quote per maker per RFQ. A re-quote replaces your earlier quote in place, under a NEW clOrdId since revision 3.85: a request or a quote whose clOrdId you already used (on an order, a swap take, a request or a quote) answers 2009 and opens or replaces nothing, with no restatement of the original (read GET /v1/rfq/mine or GET /v1/rfq/quotes/mine), from the venue's replay-contract line for that release, so a quote retried with the SAME clOrdId is safe and a stale quote can never come back. An RFQ holds at most 64 live quotes (2012). Quoting your own member's RFQ gives 2026. An RFQ that is unknown, closed, expired, or outside your eligibility set gives 2024; the cases are deliberately indistinguishable, so an id probe leaks nothing. The response echoes the quote:

{ "code": 0, "msg": "ok",
  "data": { "quoteId": 8804, "rfqId": 3101, "symbol": "BTC-USD-KO",
            "price": "64950", "expiryTs": 1785000042000, "clOrdId": "rfq-mk-77" },
  "asOfSeq": 104958, "ts": 1785000012000 }

Accept a quote

{ "quoteId": 8804, "reg": { "traderId": "TR-12-9F3A21BC" } }

Only the requester can accept, and acceptance is atomic: validation, margin on both parties and execution happen in one sequenced command, and the RFQ closes with the trade. What executes depends on the market kind:

Rejections: 2024 when the RFQ is unknown, closed, expired or not yours; 2025 when the quote is unknown, withdrawn, expired, or its maker can no longer trade (including a maker moved to reduce-only after quoting); 2026 self-acceptance; 2027 when barrier terms fail re-validation against the executed entry (or, on a close request, the quote no longer lies strictly inside the contract's terms); 2035 when a close request's contract is no longer open or held; 3002 when your own member is reduce-only or otherwise barred from opening new risk. A quote that has drifted outside the instrument's price band against the CURRENT mark is stale and rejects with 2003: the venue will not execute a negotiated price far off the market it marks against, so re-request and accept a fresh quote. Margin is checked on both parties at accept: your failure gives 3001, the quoting member's failure gives 3007. Position limits likewise: yours 2011, the counterparty's 3007. A margin, limit or staleness rejection executes nothing and leaves the RFQ open with its quotes, so you can accept a different quote inside the window.

Barrier accept guard (revision 3.55; in force on every environment). On the accept of an OPENING barrier request, five additional checks run against the CURRENT mark and the request's own terms: the accepted entry must lie within the market's published barrierGuard.entryBandBps of the mark (GET /v1/instruments; 50 bps unless the market sets its own, revision 3.70) and the mark must be FRESH (younger than the market's staleness timeout, 60 s on the current barrier listings), else 2039 QUOTE_OFF_MARKET (also answered while the mark is stale or absent); a takeProfit the mark has already reached (BUY: at or above it, SELL: at or below) rejects 2040 TAKE_PROFIT_REACHED; a barrier the mark has already reached or crossed (BUY: at or below it, SELL: at or above) rejects 2043 BARRIER_REACHED, the loss-side mirror of 2040 (the contract would knock out on the first tick after opening, forfeiting the holder's premium); and the takeProfit and the barrier must each sit at least the market's barrierGuard.minTakeProfitBps / minBarrierBps of the entry (10 bps unless the market sets its own) away from the accepted entry (2041 / 2042; a distance exactly at the floor passes). Nothing trades on any of these, the request stays open and the quote stays open too. The listing value of the band (50 bps) and its calibration rule are published in the knock-out contract specification; on the sandbox EUR-USD-KO, GBP-USD-KO and JPY-USD-KO carry 20 bps and XAU-USD-KO, SP500-USD-KO and NDX100-USD-KO 30 bps from the date venue operations announce, and since revision 3.75 USDJPY-USD-KO 20 bps and US500-USD-KO and US100-USD-KO 30 bps. The EARLY-CLOSE accept is deliberately not banded against the mark: a fair close price is the contract's remaining value, not the spot. QUOTING MEMBERS: refresh or withdraw your barrier quotes when the mark moves; an unexpired quote can otherwise be accepted against you right up to these fences.

{ "code": 0, "msg": "ok",
  "data": { "rfqId": 3101, "quoteId": 8804, "tradeId": 55900,
            "symbol": "BTC-USD-KO", "side": "BUY", "price": "64950",
            "qty": "10", "contractId": 41,
            "barrier": "60000", "takeProfit": "70000", "contractExpiryTs": 1785086400000,
            "strictTakeProfit": false, "premium": "44550", "premiumBps": 9000,
            "ts": 1785000012345 },
  "asOfSeq": 104990, "ts": 1785000012346 }

The same accept on a close request (revision 3.44), the contract closing at the writer's 67000 quote:

{ "code": 0, "msg": "ok",
  "data": { "rfqId": 3140, "quoteId": 8931, "tradeId": 55977,
            "symbol": "BTC-USD-KO", "side": "SELL", "price": "67000",
            "qty": "10", "contractId": 41,
            "barrier": "60000", "takeProfit": "70000", "contractExpiryTs": 1785086400000,
            "closeContractId": 41, "settlePrice": "67000", "realizedPnl": "20500",
            "strictTakeProfit": false, "premium": "44550", "premiumBps": 9000,
            "ts": 1785003000000 },
  "asOfSeq": 105120, "ts": 1785003000001 }

Every accepted RFQ, a barrier entry included, publishes a trade on the public trades feed and in GET /v1/executions flagged RFQ (BARRIER_CLOSE for the closing trade of an accepted close request), carrying the clOrdId of your RFQ (as requester) or of your quote (as maker), so RFQ fills reconcile through the same pipeline as book fills. A bilaterally negotiated price is not public book liquidity, so an RFQ trade deliberately does not update the last-trade print, does not fire conditional orders and does not feed the circuit breaker.

Since revision 3.70 every PERP and BARRIER execution payload (the synchronous order answer's executions, GET /v1/executions, the WebSocket execution frame) and the RFQ accept answer carry uti, the EMIR unique transaction identifier of the VENUE leg: the venue's LEI followed by the tradeId zero-padded to 12 digits. It is derived at read time from the durable trade id, so the same fill reads the same uti on every surface and on every later read; a SPOT fill and a yield contract take never carry it, and it is OMITTED (never null) until the venue has configured its LEI.

Withdraw an RFQ or a quote

The requester withdraws the whole RFQ; every live quote dies with it. Returns { "rfqId": 3101, "status": "CANCELED" }. 2024 when the RFQ is unknown, already closed, expired or not yours; the cases are deliberately indistinguishable.

The maker withdraws its live quote. Returns { "rfqId": 3101, "quoteId": 8804, "status": "CANCELED" }. 2024 when the RFQ is gone, 2025 when the quote is not yours or no longer live.

Like order cancels, neither route consumes a rate-limit token and neither is ever throttled: a member must always be able to withdraw a price. Both still require a TRADE credential (1005 on drop copy).

Barrier (knock-out) contracts

A barrier market is its own instrument with its own symbol and its own mark-price feed (for example BTC-USD-KO on the sandbox), served by the same /v1/mark-price route as every other market. The RFQ requester is always the holder and the quoting member always the writer. BUY makes the holder long with the knock-out barrier below the entry; SELL makes the holder short with the barrier above. The requester fixes barrier.level, the optional barrier.expiryTs and the optional barrier.takeProfit when opening the RFQ; makers quote the entry price.

Knock-out

The first time the mark price touches or crosses the barrier, the contract terminates at the barrier price. That holds even if the mark gaps straight through: it is a guaranteed stop with no gap risk on the holder side.

Take profit (revision 3.43)

The optional second exit. barrier.takeProfit sits on the profit side of the entry, above it for a long holder and below it for a short one, so the two levels always bracket the entry; it is checked against the current mark at create and against the quoted entry at quote and accept, strictly beyond it by at least one tick (2027 otherwise). The first time the mark reaches it (long: at or above, short: at or below) the contract terminates at the take-profit price, fee-free like a knock-out, and the holder banks |takeProfit - entry| x qty in contract value, the writer paying it. A gap through the level still settles at the level, guaranteed on both sides, and one tick can never cross both levels because they lie on opposite sides of the entry. Without a take profit the contract behaves exactly as before.

Expiry

With expiryTs set, the contract settles at the mark on the first price tick at or past that time, take profit or not: the price P&L floored at minus the premium and capped at the potential profit. On a STRICT take-profit contract (revision 3.45) the expiry without a touch settles at minus the premium whatever the mark. Without expiryTs the contract is open-ended and runs until knock-out, take profit, early close or tear-up, on a market that publishes no maxContractLifeHours; a market that publishes one refuses an omitted or later expiryTs with 2027 (revision 3.70).

Premium, knock-out rebate and strict take profit (revision 3.45)

The holder's maximum loss is its PREMIUM, |entry - barrier| x qty x contract value x premiumBps / 10000 (floor), where premiumBps is FROZEN on the contract at the open: 10000 - knockOutRebateBps on a normal contract (the market's knock-out REBATE from GET /v1/instruments; 1000 bps = 10 percent on every barrier market listed today, so the premium is 90 percent of the distance and the writer gives the rebate share back at a knock-out), the market's strictTakeProfitPremiumBps on a STRICT take-profit contract (5000 bps = 50 percent today), 10000 on every contract opened before the rebate existed. barrier.strictTakeProfit: true asks for the strict variant: it pays ONLY if the take profit is touched before the expiry, forfeits the whole premium at expiry otherwise, and needs a takeProfit, an expiryTs at most 24 hours ahead and a market whose strict share is nonzero (2027 otherwise, re-checked at accept). Every RFQ view, the accept response, the GET /v1/barriers rows and the WS barriers frames carry strictTakeProfit, premium and premiumBps.

Early close (revision 3.44)

The holder asks the writer to close the contract before any of the above: POST /v1/rfq with symbol and closeContractId (no side, qty or barrier: the venue derives the closing side, the full quantity and the terms; 2013 if sent, 2035 if the id is not an open contract you hold or already has a close request open). The request is on the writer's board only and only the writer may quote it (2024 to anyone else), at a price strictly inside the terms (2027). The holder's accept closes the contract AT that price: a BARRIER_CLOSE trade with maker/taker fees like the entry, a zero-sum BARRIERSETTLE settlement, terminationReason EARLY_CLOSE, no margin admission; the accept response carries contractId, closeContractId, settlePrice and your realizedPnl. One close request per contract at a time; a contract that terminates first cancels its open close request in the same command; cancelling one is free.

Holder margin

The premium at entry, IM equal to MM, and from then on the REMAINING distance from the mark to the barrier less the knock-out rebate (the premium plus the unrealized P&L, floored at 0); a take profit does not change it. The premium IS the maximum possible loss: no outcome of the contract, knock-out included, can cost the holder more. Because the requirement shrinks exactly as the unrealized loss grows, the contract never moves its holder toward maintenance on its own; a gain instead grows the requirement, so profit stays reserved until the contract closes.

Writer margin

Margined like a perp on the instrument's risk tiers at current notional, initial and maintenance, with mark-to-market P&L the exact negation of the holder's. When the contract carries a take profit the writer's maximum loss is bounded by the take-profit distance times quantity, so the requirement is the SMALLER of the tiered figure and the remaining mark-to-take-profit distance times quantity times contract value: a bounded contract never over-margins the writer. The knock-out rebate adds no writer requirement (revision 3.45): at a knock-out the writer still receives the premium, its worst case stays the take-profit side.

Liquidation tear-up

A member that enters liquidation has its barrier contracts, in both roles, torn up at the mark clamped to the contract's terms (never beyond the barrier or the take profit); the counterparty gets a fair close. The member's open RFQs are canceled and its outstanding quotes withdrawn at the same moment. If the venue delists a barrier market, remaining contracts are closed out at an operator-determined settlement price.

Funding and fees

No funding on barrier markets, ever. Entry pays ordinary maker/taker fees on the entry notional (holder taker, writer maker), and an early close pays them again on the closing notional (same roles); knock-out, take-profit and expiry settlement are fee-free. Settlement P&L books in the ledger as kind BARRIERSETTLE, zero-sum between holder and writer.

Barrier contracts are bilateral. They never appear in /v1/positions, never contribute to open interest and never create end-client sub-positions; the holder's and writer's clientUid attributions ride the contract itself.

Your barrier contracts

Your contracts in both roles. With status omitted or OPEN: the live contracts, marked to the live mark, exactly as before revision 3.43. status=CLOSED: your recently settled contracts, newest first, kept since the last venue start (limit default 100, maximum 1000; the durable record is your statement and the ledger). status=ALL: both, live rows first. Any other value gives 2013. data is an ARRAY. Since revision 3.57 your WRITER rows (live and closed) additionally carry capacity and, on FOR_CLIENT contracts, clientTag, your per-viewer pseudonym of the HOLDER's end client (writer transparency, above); holder rows never carry the pair.

{
  "code": 0, "msg": "ok",
  "data": [
    {
      "contractId": 41, "symbol": "BTC-USD-KO",
      "role": "HOLDER", "direction": "LONG", "qty": "10",
      "entry": "64950", "barrier": "60000", "takeProfit": "70000",
      "strictTakeProfit": false, "premium": "44550", "premiumBps": 9000, "status": "OPEN",
      "markPrice": "65400",
      "barrierDistance": "0.082568", "unrealizedPnl": "4500",
      "margin": "49050", "expiryTs": 1785086400000,
      "clientUid": "CLIENT-A", "openedTs": 1785000012345
    }
  ],
  "asOfSeq": 105010, "ts": 1785000020000
}

A closed row (?status=CLOSED or ALL) drops the mark-derived members and carries the settlement instead:

{
  "contractId": 41, "symbol": "BTC-USD-KO",
  "role": "HOLDER", "direction": "LONG", "qty": "10",
  "entry": "64950", "barrier": "60000", "takeProfit": "70000",
  "strictTakeProfit": false, "premium": "44550", "premiumBps": 9000, "status": "CLOSED",
  "expiryTs": 1785086400000, "clientUid": "CLIENT-A", "openedTs": 1785000012345,
  "settlePrice": "70000", "realizedPnl": "50500",
  "terminationReason": "TAKE_PROFIT", "closedTs": 1785003600000
}

Yield contracts: offers, takes and your contracts (revision 3.51)

A SWAP market (USD-TBILL-SWAP, EUR-TBILL-SWAP, BTC-STAKE-SWAP, ETH-STAKE-SWAP, SOL-STAKE-SWAP, USD1-STAKE-SWAP on the sandbox) trades a bilateral yield contract in ONE asset, the market's baseAsset: a writer posts an offer, a taker hands over a size of the asset, and principal plus a reward frozen at the take come back at maturity. There is no price, no mark and no margin on a swap market; GET /v1/instruments publishes swapMinTenorDays, swapMaxTenorDays, swapMaxRateBps, baseAsset, qtyStep, minNotional (the minimum single take, in the asset), maxOrderQty (one offer, one take) and maxPositionQty (your open swap size on the market in both roles). The economics, the default and claim mechanics and the disclosure your clients must see are in the member reference section 6h and the contract specification sheet; this page is the route surface.

{ "symbol": "BTC-STAKE-SWAP", "qty": "0.5", "rateBps": 450, "tenorDays": 30,
  "minQty": "0.01", "expiresInMs": 86400000, "clOrdId": "offer-0001", "clientUid": "HOUSE" }

rateBps is the annualised rate you pay in whole basis points, tenorDays the tenor of every contract taken from the offer, qty the size on offer, minQty the smallest single take you accept (default and floor: the market's minNotional), expiresInMs the validity of the standing offer (default 24 h, 60 s to 30 days). NO side, barrier or closeContractId (2013). Terms outside the market reject 2036; a writer with an outstanding claim rejects 3008. The answer is the RFQ view with kind SWAP, rateBps, tenorDays, minQty, remainingQty, asset, expiryTs and no quotes member.

The OFFERS BOARD: every live offer you may take, writers anonymous, your own offers excluded (they sit on GET /v1/rfq/mine with their live remainingQty), Market Segments applied, sorted rateBps descending then rfqId. Rows carry rfqId, symbol, kind, side BUY (the writer receives the asset), asset, rateBps, tenorDays, qty, remainingQty, minQty, expiryTs, createdTs. Polled, never pushed.

{ "qty": "0.25", "clOrdId": "take-0001", "clientUid": "CLIENT-A" }

{ "code": 0, "msg": "ok",
  "data": { "rfqId": 5102, "quoteId": 0, "tradeId": 88240, "symbol": "BTC-STAKE-SWAP", "side": "SELL",
            "price": "450", "qty": "0.25", "contractId": 17, "notional": "0.25", "rateBps": 450,
            "tenorDays": 30, "reward": "0.000924", "maturityTs": 1789603200000, "asset": "BTC",
            "fee": "0.00005", "remainingQty": "0.25", "ts": 1787011200000 } }

qty must be at most the offer's remainingQty and your maxOrderQty, and at least max(minQty, minNotional) unless it is the whole remainder (2038 otherwise); no quoteId (2037); not your own offer (2026); you must be able to pay qty plus your taker fee in the asset (3004); a writer no longer fit answers 3007 and the offer is withdrawn (a writer at its caps answers 3007 and the offer stays); an offer whose writer is outside your Market Segments answers 2024 before every other check, whatever the body says. reward is floor(notional x rateBps x tenorDays / 3,650,000) in the asset, frozen; maturityTs is the take time plus tenorDays x 24 h. Withdrawing the untaken remainder is POST /v1/rfq/{rfqId}/cancel, the writer's, never rate-limited.

Your swap contracts, both roles. status omitted or OPEN: the live ones (status OPEN, or DEFAULTED while a claim is outstanding); CLOSED: your recently settled contracts (newest first, limit default 100, maximum 1000, kept since the last venue start; the durable record is your ledger and the swaps event stream); ALL: both, live first.

{ "code": 0, "msg": "ok",
  "data": [ { "contractId": 17, "symbol": "BTC-STAKE-SWAP", "asset": "BTC", "role": "TAKER",
              "qty": "0.25", "notional": "0.25", "rateBps": 450, "tenorDays": 30, "reward": "0.000924",
              "status": "OPEN", "paid": "0", "outstanding": "0",
              "openedTs": 1787011200000, "maturityTs": 1789603200000,
              "rfqId": 5102, "tradeId": 88240, "clientUid": "CLIENT-A" } ] }

The codes introduced with RFQ, with their exact wire wording:

As everywhere on the API: log msg, branch on code. All twelve join the full registry on the Reference page.

DLT Market: tokenised securities on the Kronos X chain

Since Member API revision 3.66 (2026-09-10). PM MTF Ltd operates a DLT trading and settlement system under Regulation (EU) 2022/858. A DLT financial instrument (a share, a bond, a money-market instrument or a fund unit) is a market with kind: SECURITY on GET /v1/instruments; its baseAsset is the ISIN and equals isin. It trades exactly like a SPOT market (fully prefunded, no positions, no margin, no funding, no reduceOnly, unitScale above 1 for fractional shares) and settles on the Kronos X chain, the venue's permissioned ledger.

Every fill creates a settlement obligation. The venue folds it into a DvpSettle transaction from the seller's client wallet to the buyer's client wallet; validators re-execute the block and sign it; the block is final when two thirds of the validator set including one validator not operated by the venue have signed, typically within two seconds. Entry and irrevocability are the acknowledged fill; finality is the attested block. Your engine balance in the ISIN is the mirror of what the chain holds in trading for you.

The public record needs no authentication: GET /chain/v1/head, /chain/v1/blocks, /chain/v1/blocks/{height}, /chain/v1/tx/{hash} (with a Merkle inclusion proof), /chain/v1/tokens, /chain/v1/tokens/{isin} (with the integrity of issue), /chain/v1/wallets/{id}, /chain/v1/wallets/{id}/proof?isin=, /chain/v1/validators, /chain/v1/integrity, /chain/v1/settlements; the explorer at https://explorer.perpetuals.com renders the same data. Wallets are key hashes; no member or client identity is on the public record.

Since revision 3.68 the public record also serves GET /chain/v1/valuation, the Article 3 figures of Regulation (EU) 2022/858 (the explorer's Valuation page): status (OK, WATCH, ADMISSION_CAP, TRANSITION), aggregateEur, the thresholds (EUR 500 million issuer market capitalisation per share, EUR 1 billion issue size per bond or money-market instrument, EUR 500 million assets under management per fund unit, EUR 6 billion aggregate admission cap, EUR 9 billion transition figure), the ECB USD per EUR rate in use, and per instrument the circulating units, the price with its source (AUCTION, the closing or opening auction price, else LAST_TRADE, else MARK), the market value in EUR, the declared basis and the class cap. The venue admits a new instrument only with a recorded declaration inside its class cap and with room under the aggregate cap; nothing in this changes your order entry.

Since revision 3.70 the same record publishes monthlyAverage, the Article 3(4) monthly average aggregate market value of the last complete calendar month (month, days, aggregateEur, status, perIsin[]), and monthlyAverageRule. The arithmetic is the Regulation's own and there is exactly one: per instrument the mean of its daily EUR closing prices over the days of the month it was priced times the units recorded on its last day (an instrument unpriced all month at its declared basis), perIsin[].averageEur being that contribution and aggregateEur their sum, the same figure the admission refusal projects from. The Regulation applies that average to admissions in the following month and to the transition decision: the venue refuses a new instrument when either the live aggregate at the moment of admission or the monthly average would reach the EUR 6 billion cap, and decides the transition strategy on the monthly average, a single day above EUR 9 billion being a warning and not an activation. The figure is frozen once its month closes; while fewer than one complete month is recorded the field is null and the rule sentence says so.

Call auctions on SECURITY markets

Since Member API revision 3.67 (2026-09-10). A SECURITY market may carry an auction schedule: one opening and one closing call per calendar day at local times in the market's zone. GET /v1/instruments publishes it as auction (schedule, zone, openCallStart, openUncross, closeCallStart, closeUncross) with the live tradingPhase and, after the first uncross that traded, lastAuctionPrice and lastAuctionTs. A SECURITY market without the block trades continuously exactly as before.

At the scheduled time the venue computes one price and executes every crossing order at it: the price with the largest executable volume, ties broken by the smallest surplus, then by closeness to the reference (the last trade, which an auction print also updates, else the mark), then the lower price; a candidate outside the market's priceBandBps around the reference is not eligible. Orders pair in price and time priority; every print carries flags: "AUCTION" and both sides pay the maker fee rate. If no price trades, the call ends with an empty uncross and the phase advances; resting orders stay. Two rules since revision 3.69: a due uncross on a halted market is deferred, the phase stays in the call and the uncross runs when the halt lifts; and when a call ends with orders still crossing (the collar excluded every candidate, a same-member or ineligible pair), the entry into continuous trading replays those orders in time priority through ordinary matching, so the earlier order rests and the later one takes at the resting price with the ordinary fees and no AUCTION flag. The public status.{symbol} channel carries { tradingPhase, nextPhaseTs } on each phase change and { auction: { price, qty, surplusQty, surplusSide } } on each uncross. The closing auction price is the DLT Market's daily valuation.

Client identity for transaction reporting (RTS 22)

PM MTF Ltd, as the operator of this MTF, owes a transaction report under MiFIR Article 26(5) for every transaction executed through its systems by a member that is not itself a MiFID II investment firm. Where such a member's trade carries client flow, the venue's report must identify the underlying client per RTS 22 Annex I Table 2. This surface is how members supply that identification, keyed by the same clientUid they already stamp on every order. Members that ARE MiFID II investment firms report their own transactions: the venue does not report for them and nothing here applies to them. A market maker that is in scope can register its own LEI against its house clientUid (the configured house identifier applied when it omits clientUid on order entry) so own-account sides resolve too.

All three routes are signed like every private route and metered on the read bucket (the PUT is reference data, not order entry, so it never consumes an order-budget unit). They are served from the venue's history store: a deployment without it answers 5004 with HTTP 503 on all three. A path clientUid that begins or ends with whitespace rejects with 2013 on the PUT and on the GET since revision 3.72. The identity store sits outside the engine sequence, so the envelope asOfSeq is 0 on the PUT and the single-record GET; the missing report's asOfSeq is the projection watermark instead.

Create or update the record for one clientUid (the identifier exactly as you stamp it on orders, 1 to 64 characters). An upsert: the same route is the update mechanism, and every PUT both replaces the current record and appends an immutable audit revision, so a corrected report can show what was on file at any earlier revision. Requires a trading-capable credential; a READ_ONLY (drop copy) key is refused with 1005. The body is STRICT like order entry: an unknown JSON field rejects with 2017, never a silent discard.

{
  "type": "NATURAL_PERSON",
  "countryCode": "DE",
  "identifierPriority": 2,
  "nationalIdType": "PASSPORT",
  "nationalId": "C01X00T47",
  "firstName": "Jürgen",
  "surname": "Müller",
  "dateOfBirth": "19840217"
}

For a natural person who holds more than one nationality, choose countryCode as RTS 22 Article 6(3) and the ESMA transaction reporting guidelines (ESMA/2016/1452, section 5.5.1) direct: an EEA nationality over a non-EEA one, and among several nationalities of the same kind the ISO 3166-1 alpha-2 code that sorts first (a German and United States national is DE, a Brazilian and United States national is BR, a British and German national is DE because the United Kingdom is outside the EEA); the venue evaluates the identifier against that country's row and never re-derives the choice from data it does not hold.

Cross-field rules: lei only on LEGAL_ENTITY; dateOfBirth, nationalId and nationalIdType only on NATURAL_PERSON. Any validation failure rejects with 2030 and a msg naming the offending field. The response echoes the stored record:

{
  "code": 0, "msg": "ok",
  "data": {
    "clientUid": "CLIENT-A", "type": "NATURAL_PERSON",
    "countryCode": "DE", "identifierPriority": 2,
    "nationalIdType": "PASSPORT", "nationalId": "C01X00T47",
    "firstName": "Jürgen", "surname": "Müller", "dateOfBirth": "19840217",
    "lei": null,
    "mifirId": "C01X00T47", "mifirIdSource": "NATIONAL_ID",
    "revision": 1, "updatedAt": 1785000000123
  },
  "asOfSeq": 0, "ts": 1785000000123
}

mifirId is the identifier the venue's transaction report will carry for this client, resolved at submission time and stored resolved, so what the GET shows is exactly what will be reported. mifirIdSource says how it was chosen: LEI (legal entities), NATIONAL_ID (a natural person with a designated national identifier), or CONCAT. When a natural person has no nationalId, the venue derives the RTS 22 Annex II fallback identifier exactly as the ESMA transaction reporting guidelines (ESMA/2016/1452, section 5.5.1) prescribe: countryCode + dateOfBirth + the first five letters of the first name + the first five of the surname, each name part padded to five with #. The venue applies the four ESMA steps itself: titles are removed from both fields (Dr, Prof, Mr, Mrs, Ms, Sir, Madame and the rest of the ESMA list, case-insensitive, with or without a trailing dot); the listed surname prefixes are removed when they stand as separate leading words (van, van der, von, de, de la, di, da, dos, du, mac, mc, o, ó, ní and the rest of the list, longest match first; a prefix written into the name is kept, so McDonald, O'Brian and Vandenberg keep it; a listed prefix or title that is the whole field is the name and stays, Le derives LE###), and only the FIRST first name is used (Jon Ian derives JON##; a hyphenated first name is one name, Amy-Ally derives AMYAL); then the ESMA transliteration table is applied character by character and uppercased: every character in the table folds to its listed Latin letter (Ø to O, ß to S, Æ to A, Þ to T, Œ to O), and every character outside the table, apostrophes, hyphens, spaces, digits and letters of other scripts included, is removed. The body above submitted without nationalId would store "mifirId": "DE19840217JURGEMULLE" (Jürgen folds to JURGE, Müller to MULLE). A name with no letter the table can fold (a name written only in Greek or Cyrillic, for example) is refused with 2030: resubmit the names in their transliterated Latin form, or supply nationalId and nationalIdType. Identifiers stored under the earlier derivation are re-derived by the venue under a new audit revision.

The current record, in exactly the shape above; a clientUid with no record answers 2031 (HTTP 404). A READ_ONLY credential may call it, so a back-office reporting process can verify coverage without being able to trade.

The identity behind one Trader ID (revision 3.53; RTS 22 fields 57 to 60, the Member API reference section 6d): every PUT appends an immutable audit revision (immutable until the retention floor), needs a trading-capable credential (1005 otherwise), and the path id is 1 to 64 characters of A-Z a-z 0-9 . _ -; it need not be a registered Authorised User, because decision codes may name persons who never enter orders. The GET answers the current record, or 2031 (HTTP 404) when none is on file or after the venue pseudonymised it.

The chase list for the reporting window: every distinct clientUid of your member that traded on MiFIR-scope markets (the perpetual, the barrier since revision 3.52 and the swap markets from the date venue operations announce under revision 3.70: barrier contracts and yield contracts are derivatives traded on the MTF and their trades are transaction-reportable) inside the window and has no identity record on file. Spot activity does not appear. A member whose licensing profile records it as a MiFID II investment firm always receives an empty clients array (revision 3.70): the venue reports nothing for it and keeps no chase list for it. The identity record serves the venue's own regulatory reporting only, its MiFIR Article 26(5) transaction reports and, where a surveillance alert concerns the client, the suspicious transaction and order report (STOR) the venue files with CySEC; it is never read by matching, margin or any risk path and is disclosed to no other member.

{
  "code": 0, "msg": "ok",
  "data": {
    "from": 1784913600000,
    "to": 1785000000000,
    "clients": [
      { "clientUid": "CLIENT-B", "tradeSides": 7,
        "firstTradeTs": 1784920000123, "lastTradeTs": 1784999911456 }
    ]
  },
  "asOfSeq": 104870, "ts": 1785000000456
}

Rows are ordered oldest first trade first, so the entries closest to the deadline come first. tradeSides counts your trade sides carrying that identifier inside the window; firstTradeTs and lastTradeTs bound them. An empty clients array means every reportable side in the window is covered. The envelope asOfSeq is the projection watermark: the report sees trades only up to that sequence, so a trade acked a moment ago may not be visible in it yet. For an end-of-day sweep this does not matter; for a trade-then-poll integration test it does.

The codes introduced with this surface, with their exact wire wording (the 2030 msg is usually more specific and names the offending field):

The record exists solely to populate buyer and seller identification in the transaction reports the venue owes; it is never read by matching, margin or any risk path, and it is disclosed only through the venue's own regulatory reporting, never to another member. REST only: there is no WebSocket op and no FIX surface for identity data.

Account, positions and margin

{
  "code": 0, "msg": "ok",
  "data": [
    {
      "ccy": "USD", "balance": "1250000", "equity": "1261430.5",
      "unrealizedPnl": "11430.5",
      "positionIM": "184000", "orderMargin": "22500", "MM": "92000",
      "available": "1054930.5", "spotReserved": "0",
      "marginRatio": "0.0729", "riskStatus": "NORMAL", "imMultiplier": "1",
      "feeTier": "TIER_2", "makerFeeRate": "0", "takerFeeRate": "0.0004",
      "assets": [{ "asset": "BTC", "total": "3.5", "reserved": "0.5", "free": "3" }]
    }
  ],
  "asOfSeq": 104905, "ts": 1785000000600
}

riskStatus is one of NORMAL, MARGIN_CALL, LIQUIDATION, DEFAULTED. imMultiplier is "1" unless the venue runs your account at a stricter margin profile. feeTier, makerFeeRate and takerFeeRate are omitted when you trade at per-instrument default fees; a negative maker rate is a rebate. spotReserved is cash promised to open spot buy orders and is already excluded from available. MM is the same quantity the WS margin channel reports as lowercase mm; the spellings differ, the number does not. GET /v1/account/margin serves the identical payload and exists as a cheap polling alias.

Your effective parameters, GET /v1/account/parameters (revision 3.61)

Since revision 3.62 the gateway-side blocks carry the published CLASS you sit in and the values in force: account.rateLimits (the rate-limit ladder: per-minute rates and the per-SECOND burst ceiling ordersPerSecBurst, enforced beside the per-minute bucket where your class publishes one, published 2026-09-10: STANDARD 1,000, DMA 3,000, MM 5,000 orders/s on production, 0 on the sandbox; one source per value, VENUE the STANDARD class, CLASS a published class, MEMBER a tighter value of your own; a raise is only ever a class assignment), account.otr (the order-to-trade class and thresholds in force, the published windowMinutes 60 and minOrders 100, and the prepared surcharge row, not in force by venue decision and applied to nobody while enabled is false: no order-to-trade surcharge applies, one may be introduced only by an amendment of the published fee schedule announced at least seven Business Days ahead), account.dea (the DEA-flow class and limits on reg.dea orders per UTC day, usedToday, and the identifiers stopped on your account: reject 3010 on their reg.dea orders, 3011 at the flow limit) and account.fees (the tier the published measurement cycle put you in with criteria, volume30d, measuredAt and cycle, and pending: every rate change of the schedule that will touch you with its effectiveFrom; a rate never changes before the published date, and a member-market rate exists only as an enrolment in a published programme). account.fees itself is never null, but its measuredAt, volume30d and cycle read null until the first measured fee cycle that includes your account, and so do tier and criteria unless you are enrolled on a Market Maker Scheme tier, which they then name with its obligations (the first-of-month 00:00 UTC boundary: a member admitted after the last cycle, and every member of a venue started after it, reads null until the next one, unless venue operations run a measurement before it); a null there means not measured yet, never a fee of zero, and the fee deducted on each market is on every markets[] row, makerFeeRate and takerFeeRate with their source (revision 3.83 states it; nothing changed). Your own self-trade prevention election is PUT /v1/account/stp.

Since revision 3.63 every market row also carries stpSource and stpScopeSource (MEMBER the account policy, SELF a value you set under a self-service scope, MEMBER_MARKET a per-market value venue operations set at your request, SELF_MARKET your own per-market election on PUT /v1/account/stp with symbol) and eligibility { restricted, source, memberLayer, marketLayer }, the Market Segments layers in force on that market (source is VENUE for open to all, MEMBER for your account configuration, MEMBER_MARKET for your per-market layer; marketLayer is absent while you never wrote one); the account block carries stpSource and stpScopeSource.

Your own tighter limits (PUT /v1/account/parameters, revision 3.64). Beside the values venue operations set, you may set your own pre-trade limits within the venue's rules (RTS 7 Article 20, RTS 6 Article 15): TRADE credential, body { "symbol"?, "set": { name: value }, "clear": [ name ] }. Without symbol the write is account-wide and may name maxOpenOrders, imMultiplier, priceBandBps, marketMaxSlippageBps, maxOpenRfqs and maxOpenContracts; with symbol it is for that market alone and may also name maxOrderNotional, maxOrderQty, maxPositionNotional and maxPositionQty (quantities, notionals and the multiplier as decimal strings, counts and bps as integers). The venue resolves the TIGHTEST of the market rule, any value venue operations set for your account and your own value, so a value of yours can only tighten what is in force: a looser one is refused with 5003 and a sentence naming the rule before anything is written (for example maxOrderQty 60 would loosen the value venue operations set for your account on BTC-USD-PERP (50): a self-set value can never loosen the venue's; the multiplier is a maximum, so there a smaller value is the loosening). A per-market value without symbol and a name that is not self-service (withdrawalBuffer, sessionStatus and access, which are venue measures, and stp / stpScope, which are PUT /v1/account/stp) are refused the same way; an unknown symbol is 2001. A cleared name reverts to the venue's rule; venue operations never edit your own values; a value of yours that a later, tighter venue rule beats stays stored and is listed under inert. The answer is { scope: ACCOUNT | MARKET, symbol, set, cleared, parameters }, parameters being exactly the GET read afterwards. On the read a value of yours in force shows as source SELF (account-wide) or SELF_MARKET (that market), and self { account, markets: [ { symbol, values } ] } lists every value you hold raw, including one that merely ties the rule in force. Your other sessions receive a MEMBER_PARAMS frame with origin MEMBER. The member portal's "API and limits" page offers the same controls.

The rules of every market are public on GET /v1/instruments (bands, caps, the circuit breaker, the staleness timeout, the liquidation parameters, the funding band and rate source, the per-market open-order ceiling, the access mode, the barrier guard, the swap offer validity, the trading hours). This read answers what applies to YOU after every member-specific tightening, and only ever your own values. Every row is { value, source }: value is written even when null (no rule at any scope), source names the scope that supplies it, one of VENUE, MARKET, MEMBER (a value venue operations set for your account on every market), MEMBER_MARKET (on this market), LEGACY (the historical per-account quantity override) and, on the fee rows, INSTRUMENT, TIER, PROGRAMME (on swap market rows always INSTRUMENT since revision 3.70); the set is open. A stored value a tighter scope beats is listed under inert on the same row. The account block carries maxOpenOrders, imMultiplier, withdrawalBuffer, priceBandBps, marketMaxSlippageBps, maxOpenRfqs, maxOpenContracts, stp, stpScope, your rateLimits and otr classes, dea, fees, marginWatchPct and legacy; every markets[] row carries access (ALLOWED / DENIED), sessionStatus, the per-market open-order ceiling, the order and position caps in force for you, imMultiplier, band, collar, the RFQ and contract caps, the fee rates with their source, STP and eligibilityRestricted. A member-specific value can only ever TIGHTEN a market rule; it is written by venue operations against an objective published class, or as a measure with a stated rulebook ground and a case reference that the venue notifies you of by mail with the section 36 appeal route. The withdrawalBuffer row is the fraction of the amount withdrawn that must remain on your account after the withdrawal, over and above Initial Margin (with your multiplier, open orders that may increase a position included) and cash or assets reserved for your spot orders, met from your cash balance after those reservations and never from unrealised profit; the venue-wide value is published on the Website and is 0; a higher value applies to you only as the published value of a class you sit in or as a Rules measure with a ground and a case reference notified by mail and appealable under Rules section 36 (Rules section 14); a withdrawal that fails the test is refused and may be resubmitted for a lower amount, and withdrawals stay refused during liquidation or default management. Changes arrive on venueEvents as MEMBER_PARAMS frames. A READ_ONLY credential may call it.

{ "orders": [ { "symbol": "BTC-USD-PERP", "side": "BUY", "type": "LIMIT",
               "tif": "GTC", "price": "65000", "qty": "10",
               "clOrdId": "preview-1", "clientUid": "CLIENT-A" } ] }

{ "code": 0, "msg": "ok",
  "data": { "indicative": true, "accepted": true, "im": "197000",
            "mm": "98500", "available": "857930.5" },
  "asOfSeq": 104906, "ts": 1785000000610 }

Each nested order uses the full place-order schema and is validated the same way, so a malformed probe fails with the same code a real order would. The array is priced as one basket of 1 to 50 entries (more reject with 2002): perpetual entries fold into order margin together, with the same one-sided max(buy, sell) netting per instrument that resting orders receive, spot entries have their prefunding needs summed per currency, and accepted answers every gate at once, independent of array order. The figures describe the WHOLE basket, in the settlement currency of the first entry. The preview is charged to the read bucket and is permitted on a READ_ONLY credential, which is what makes it usable from a risk process that must never be able to trade. The answer is indicative: it is computed against the state at asOfSeq and the market moves.

How entries are priced. A priced entry is valued at its own limit, a conditional at the limit it would work at once armed (trigger.limitPrice), and a MARKET entry at the current mark, on perpetual and spot markets alike. The mark is what the venue already values a market order at for the per-order size cap and the minNotional floor. It is not the price a market order would get: the protection collar forms from the book at the instant of entry, so a market entry is an indication at today's mark rather than a quote. Size a market order against the book, or send a limit. On a spot market BUY the difference is a funding one: order entry prefunds it at the collar, which is normally above the mark, so a spot market buy sized to the last micro of your cash can preview accepted: true and still be rejected 3001 when you send it.

What accepted answers, entry by entry, is the same set of admission rules order entry applies: available (perpetual order margin, spot buy prefunding in cash, spot sell prefunding in base-asset units, summed per currency), the per-order size cap (2013), the minNotional floor (2028), the position cap (2011) and the reduce-only budget (2008). Reduce-only entries carry the same exemptions they carry on order entry: a reduceOnly entry is exempt from the available gate, from minNotional and from the position cap, so a reduce-only basket previewed during a margin call answers accepted: true, which is what sending it does; it is not exempt from the per-order size cap, because that cap guards closes too. What accepted does not answer is venue state that is not a property of your basket: halts, member or instrument status, and whether a market order would find liquidity.

The reduce-only budget applies to the whole basket, and it is MEMBER-level. A reduceOnly order may only close what your MEMBER book holds: order entry admits one while the reduce-only quantity already working on that market, plus the new order, stays within your member net position on the reducing side, and rejects the surplus with 2008. The preview measures your entries together against the same budget, so a basket that would close MORE than you hold answers accepted: false rather than promising an acceptance the second entry would not get, and an entry on the side that would ADD to your position, or on a market where you hold nothing, is rejected the same way. A clientUid on an entry never narrows the budget to that client's sub-position, here or on order entry: see the reduce-only warning, which matters most for an end-client close.

Entries the venue would refuse outright answer with a code, not with accepted. accepted is for the admission gates above; an entry order entry would reject before it ever reaches them fails the preview with the same code the order gets: 2016 for reduceOnly or a market-type conditional BUY on a spot market, 2013 for an out of range trigger or post-trigger limit price, 3005 for a market with no sequenced mark yet, 2002 for a limit priced at zero or a misaligned value, 2018 for a leverage or quoteCcy assertion the instrument cannot satisfy. The basket answers with the first such entry.

History

History routes are served from the venue's projection store rather than live engine memory. Their envelope asOfSeq is the store watermark, the highest sequence with no hole beneath it, not the engine head. That is an honest signal: if the watermark is behind, the answer is complete only up to the watermark, and you should poll rather than conclude that nothing happened. While the store has a recorded hole (store.status REPAIRING, see Stream recovery) GET /v1/executions and GET /v1/account/ledger serve only the rows at or below the watermark, with and without a symbol or kind filter, as the event stream routes and the rejection rows of GET /v1/orders/history do (the two since revision 3.83; before, they could carry rows from after the hole while the hole's own rows were missing). The closed-order rows of GET /v1/orders/history are not held: until the status is COMPLETE again they can include orders closed after the hole, above asOfSeq, while orders closed inside it are missing.

Closed orders and rejections. This is the only place a rejection that never reached the book can be re-read after the fact, which makes it the right source for a daily reconciliation of everything you sent.

{ "code": 0, "msg": "ok",
  "data": [
    { "orderId": 887711, "clOrdId": "a3f1c9d24b7e4f108c6d2e5b", "symbol": "BTC-USD-PERP",
      "side": "BUY", "price": "65000", "qty": "1", "remainingQty": "0",
      "status": "FILLED", "clientUid": "CLIENT-A",
      "acceptedTs": 1785000000117, "closedTs": 1785000000118 },
    { "orderId": 0, "clOrdId": "a3f1c9d24b7e4f108c6d2e5c", "symbol": "BTC-USD-PERP",
      "side": "BUY", "price": "65000", "qty": "1", "remainingQty": "0",
      "status": "REJECTED", "rejectCode": 3001, "clientUid": "CLIENT-A",
      "acceptedTs": 1785000000200, "closedTs": 1785000000200 }
  ],
  "asOfSeq": 104870, "ts": 1785000000700 }

Rows carry the optional positionSide field exactly like the live order surfaces: LONG or SHORT for an order placed with hedge mode, OMITTED (not null) on netting orders, so every pre-hedge row is byte-identical. Both rows in the example are netting orders, which is why the field does not appear. See Hedge mode under order entry.

cancelReason is one of a closed set: USER_REQUESTED, IOC_REMAINDER, FOK_UNFILLABLE, GTD_EXPIRED, STP_CANCEL, LIQUIDATION_CANCEL, ADMIN_CANCEL, INSTRUMENT_HALT, MEMBER_SUSPENDED, REDUCE_ONLY_VIOLATION, SPOT_UNFUNDED, POSITION_SIZE_LIMIT, MARKET_ACCESS (revision 3.65: the venue cancelled the order on a DENIED access decision or an admission flip), FUNDING_CATCH_UP (revision 3.70, venue-initiated: a conditional order that triggered while the market's GRID funding catch-up was pending; reduce-only conditionals execute), POST_ONLY_WOULD_CROSS (revision 3.70, venue-initiated: a post-only order that rested through a call on a scheduled SECURITY market and would cross on the entry into continuous trading). USER_REQUESTED covers every cancel of your own: a cancel on any transport, a member-wide cancel-all, the member portal's kill switch and the cancel on disconnect you armed, which the value does not tell apart (revision 3.83 states it); ADMIN_CANCEL is reserved for cancels by venue operations. The full table with which reasons are venue-initiated is on the Reference page.

Your fills, one row per leg you were party to, with fee, role (MAKER | TAKER), flags (NORMAL | LIQUIDATION | ADL | RFQ | BARRIER_CLOSE | REVERSAL), clOrdId, refSource and clientUid. Default limit 100, maximum 1000. Executions are anonymous: an execution record, here, on the WS execution channel, the FIX drop copy and the event stream, names your own side only (your order, your clOrdId, your clientUid, your fee and your role); no field identifies the member on the other side, and the venue does not disclose it except where Applicable Laws or the Rules provide for it.

Lots: a per-client lot view

A CFD-style display of an end client's open position as the individual opening fills, "lots", that built it, with a targeted per-lot close. Lots are a DISPLAY CONVENTION folded on demand from your immutable fill history: the engine keeps no lots, and margin, liquidation, funding attribution and the venue's booked realized PnL remain average-cost per sub-position. The fold changes reporting, never economics.

The fold. Lots exist per (clientUid, hedge bucket, instrument), where the bucket is the netting bucket or the hedge-mode LONG/SHORT bucket. Every fill that INCREASES the bucket's position opens a lot: its lotId is the tradeId of the opening fill and its entry price is that fill's price. Every fill that REDUCES the bucket consumes open lots: lots explicitly assigned to the reducing order first (the targeted close below), then FIFO from the oldest. A fill that crosses the bucket through zero closes every open lot and opens one new lot in the opposite direction with the remainder. The open lots' qty sums exactly to the bucket's net quantity. Per-lot unrealizedPnl is measured from the lot's OWN entry to the mark, the bucket's unrealizedPnl on GET /v1/positions/end-clients from its average cost, so the two sums agree only until a partial close leaves lots at different entry prices; from then on they differ by exactly the realized PnL the lot attribution has taken over the booked figure since the bucket was last flat (lots of 10 at 100 and 10 at 120, 4 of the first closed at 130: the closure shows 120 realized, the venue books 80, and the remaining lots' unrealizedPnl sums 40 below the bucket's). Before revision 3.80 this page said the sum was exact. The fold is CLAMPED to the live sub-position: a venue-side close the fold cannot attribute (a liquidation on an RFQ-mode market) trims the oldest open lots of the bucket, so you never see a lot the venue already closed. ADL allocations are attributed from the per-client ADL record, and since revision 3.80 a hedge-mode client's book liquidation is attributed to its own LONG or SHORT bucket (before, it was folded into the netting bucket and its lot was trimmed instead). Lots exist on order-book perpetual and spot markets; BARRIER symbols are refused by both routes with 2013, because barrier contracts are bilateral and have no lots.

Reading lots

clientUid and symbol are required; positionSide optionally filters to one bucket (NET, LONG or SHORT). Served from the history store like GET /v1/orders/history, so the envelope asOfSeq is the store watermark.

{ "code": 0, "msg": "ok",
  "data": {
    "clientUid": "CLIENT-A", "symbol": "BTC-USD-PERP", "mark": "69000",
    "settleCcy": "USD", "accFunding": "-12.5",
    "openLotsFunding": "-9.2", "closedLotsFunding": "-3.3",
    "lots": [
      { "lotId": 990312, "direction": "LONG", "entryPrice": "68000",
        "qty": "0.002", "unrealizedPnl": "2", "accFunding": "-6.1",
        "fundingIntervals": 7, "openedTs": 1785470168892,
        "openClOrdId": "my-open-17", "openOrderId": 774120 },
      { "lotId": 990840, "positionSide": "LONG", "direction": "LONG",
        "entryPrice": "68500", "qty": "0.001", "unrealizedPnl": "0.5",
        "accFunding": "-3.1", "fundingIntervals": 4,
        "openedTs": 1785470201230,
        "openClOrdId": "my-open-18", "openOrderId": 774131 }
    ]
  },
  "asOfSeq": 104870, "ts": 1785470201400 }

• Lots are grouped by bucket, NET then LONG then SHORT, and oldest first WITHIN each bucket, which is that bucket's FIFO consumption order. The array is not globally age-ordered across buckets.
• positionSide is LONG or SHORT on hedge-bucket lots and OMITTED, not null, on netting-bucket lots. direction is the lot's own direction: in the netting bucket lots flip through zero, so a netting lot can be short.
• qty is the lot's REMAINING quantity after partial consumption.
• mark and unrealizedPnl are OMITTED, not null, while the market has no mark price yet.
• openClOrdId and openOrderId are YOUR OWN references on the fill that opened the lot: the clOrdId you sent on the opening order and the venue orderId it was accepted as, so a lot is addressable by your client-generated id without a mapping table. Transport independent, so a FIX order's ClOrdID(11) lands in openClOrdId exactly as a REST clOrdId does; that is what venue tag 9028 resolves against. Both are OMITTED, not null, where the opening leg has no order of yours to name (no clOrdId sent, an RFQ acceptance leg, a venue-initiated open). Not a unique key: one order filling in several prints opens one lot per fill and every one of them carries that order's reference, and clOrdId uniqueness is only a 24 hour window. Read lotId for identity, openClOrdId for attribution.
• accFunding on a lot is the financing it has carried since it opened, in settleCcy and signed from the client's side (negative paid); fundingIntervals counts the settlements it has been open across. Both are 0 on spot, which never funds.
• The fold reads at most 100,000 fills per (clientUid, symbol) scope; past that it refuses with 2013. Reconcile such a client by positions and executions instead.

Funding on lots

The venue charges funding on the client sub-position net, once per settlement anchor, never per lot, so a per-lot figure is an attribution of a booked charge and not itself a booked figure. The attribution is exact: each anchor charges exactly the lots that were open when it settled, and the shares sum to the charge on the bucket net to the micro, with the rounding remainder booked to the largest lot, the same rule the venue uses to split a member's charge across its clients. That exactness is against the charge on the bucket net: the booked accFunding of the one client that receives the remainder of splitting YOUR member charge across your clients can differ from the sum of its lots by that remainder, which then shows in closedLotsFunding. Financing follows the quantity actually held, so a partially closed lot keeps what it incurred while it was larger, and a fully closed lot takes its financing with it.

The envelope therefore carries three figures, and all three matter:

The fold is bounded, and the bounds are published: at most 100,000 fills per (clientUid, symbol) scope, at most 20,000 funding settlements to attribute (about 18 years of an 8 hour grid, counted from the first fill the fold covers), and at most 5,000,000 attribution steps (settlements x lots open at each). Past a bound the request refuses with 2013. positionSide narrowing folds ONLY that bucket, so it reduces the attribution work in proportion; past the settlements bound, or when a single bucket alone exceeds the work bound, there is no in-API remedy: reconcile that client by positions and executions instead, and note the lot close endpoint is refused for such a scope too.

Reading closures

The close-attribution feed: every CLOSING fill in the scope, mapped to the exact lot or lots it consumed by the SAME fold that builds GET /v1/lots. The feed folds WITHOUT the clamp, so the one close it cannot list is a close the fold cannot attribute (a liquidation on an RFQ-mode market): the lots view trims that lot and no closure row names it. clientUid and symbol are required, positionSide filters to one bucket, and from and to are optional Unix ms bounds on the closing fill's ts. Rows are oldest first, and one closing fill that consumed several lots appears as one row per lot, in consumption order.

{ "code": 0, "msg": "ok",
  "data": {
    "clientUid": "CLIENT-A", "symbol": "BTC-USD-PERP", "settleCcy": "USD",
    "closures": [
      { "closeTradeId": 991402, "lotId": 990312, "qty": "0.002",
        "openPrice": "68000", "closePrice": "69100", "realizedPnl": "2.2",
        "openClOrdId": "my-open-17", "closeClOrdId": "my-close-31",
        "flags": "NORMAL", "unsolicited": false, "ts": 1785470880110 },
      { "closeTradeId": 991540, "lotId": 990840, "positionSide": "LONG",
        "qty": "0.001", "openPrice": "68500", "closePrice": "67200",
        "realizedPnl": "-1.3", "openClOrdId": "my-open-18",
        "closeClOrdId": "KX-ADL-991540", "flags": "ADL",
        "unsolicited": true, "ts": 1785471002480 }
    ]
  },
  "asOfSeq": 104903, "ts": 1785471002500 }

• qty is how much of the lot THIS row consumed, not the closing fill's total. realizedPnl is (closePrice - openPrice) x the LOT's direction x qty: FIFO attribution and presentational, since the venue books realized PnL average-cost per sub-position.
• openClOrdId is your reference on the order that opened the consumed lot; closeClOrdId is your reference on the closing order. A venue-initiated close carries none of yours, so the venue derives one in its reserved namespace: KX-ADL-{closeTradeId} for an auto-deleveraging tear-up, KX-LQ-{orderId} for a liquidation close. KX- is refused on order entry with 2020, so a derived reference can never collide with one of yours.
• flags carries the closing fill's trade flags (NORMAL, LIQUIDATION, ADL, REVERSAL), and unsolicited is true for exactly the last three: the venue closed the lot, you did not. ADL tear-ups are sourced from the per-client ADL record, because the ADL trade itself carries no client identifiers.
• This is where a targeted close is verified. An assignment is advisory and never rejects: a close that fills after the lot shrank takes what is left of it and sends only the surplus FIFO; a FIX 9020 or 9028 target that names no open lot of that client in that bucket sends the whole close FIFO; and an IOC that finds no liquidity closes nothing, so the lot stays open. Reconcile the intent you sent against what the fold recorded here.
• Same fold, same bounds as GET /v1/lots, refused with 2013 past one; unknown symbol 2001, barrier symbol 2013. The envelope asOfSeq is the history-store watermark.

Closing one lot

{ "clientUid": "CLIENT-A", "symbol": "BTC-USD-PERP", "reduceOnly": false, "clOrdId": "close-lot-1" }

Closes a specific open lot: the venue submits a MARKET IOC order on the opposite side for the lot's remaining quantity, tagged with the lot's hedge bucket, and records an ASSIGNMENT of that order to that lot, so the fold consumes THAT lot first rather than the FIFO-oldest one. The response is { "lot": {...}, "order": {...} }: the lot as the fold saw it at request time and the ordinary place-order response for the submitted close, executions included. The envelope asOfSeq here is the ENGINE sequence of the close order's ack, exactly as on POST /v1/orders; use it as the watermark the GET route must reach before the fold reflects the close.

• This is order entry. The close passes the same admission ladder as POST /v1/orders: trading-capable credential (1005 on a READ_ONLY key), one order-budget unit, the RTS 9 regime, and its order can reject exactly as any market IOC can. A rejected or unfilled close leaves the lot open. The body accordingly takes an optional reg object, same shape and rules as POST /v1/orders: a member at ENFORCE-stage capacity enforcement must carry reg.tradingCapacity here too or the close rejects 2033 (the natural value is AOTC); ungated members can omit it with no change.
• A lotId that is not an OPEN lot of that clientUid and symbol answers 2032 (HTTP 404) and nothing is submitted. An RFQ-mode market is refused with 2022 up front: the close submits a book order and an RFQ market has no book.
• One close per lot at a time: a concurrent close of the same lotId is refused with 2013, "a close for this lot is already in flight".
• clOrdId follows the usual rules, the reserved KX- prefix (2020) included, and reuse mirrors POST /v1/orders: a different payload rejects 2009 (HTTP 400), an identical payload returns the ORIGINAL order with duplicate: true, places nothing and records no assignment. The payload is built from the lot as it stands when the request arrives, so a retry with the same clOrdId after a lost response answers 2032 once the first close filled the whole lot, 2009 once it filled part of it, and can still answer duplicate: true while the history store has not folded the first close: read your executions or the closures feed before you retry.
• reduceOnly is applied only when you send it and the default is FALSE, deliberately. The reduce-only budget is member-level and never reads a client's sub-position, so a client-level close while your member aggregate leans the other way would reject with 2008 even though the client genuinely holds the lot, and a member book that nets to zero would refuse every lot close on the instrument. Sending reduceOnly: true here opts INTO that member-net precondition; leaving it alone closes the lot the client actually holds. See reduceOnly semantics.
• Races are resolved by the fills, not the assignment: an in-flight fill can consume the lot between your read and the close, an IOC that finds no liquidity leaves the lot open, and a close that fills after the lot shrank folds against what is left, FIFO for any surplus. The assignment record itself is best effort: if the history store cannot record it after the order already executed, the request still answers with the order's true outcome and the view degrades to FIFO for that close.
• The lot VIEWS (GET /v1/lots and GET /v1/lots/closures) are REST only and there is no WebSocket op, but the TARGETED CLOSE also rides FIX: venue tag 9020 (TargetLotID) names the lot, and tag 9028 (TargetOpenClOrdID) names it by the clOrdId of YOUR opening order, which the venue resolves to the lot or lots that order opened, oldest fill first, each at its full opening size so that consecutive partial closes of the same order walk its lots oldest first (revision 3.80; before it, a second partial close of an order that filled in several prints could send part of its quantity FIFO to the client's oldest lot). On FIX your side supplies the closing direction, quantity and hedge bucket, and an unknown or already-closed target degrades to FIFO rather than rejecting: verify against the closures feed. The close order itself reports on every transport like any other order, drop copy included.

Risk and unwind

{ "code": 0, "msg": "ok",
  "data": [
    { "episodeId": 4417, "role": "COUNTERPARTY", "trigger": "MARGIN_BREACH",
      "status": "CLOSED", "canceledOrderIds": [], "tradeIds": [],
      "adlAllocations": [
        { "counterpartyClientUid": "CLIENT-A", "symbol": "BTC-USD-PERP",
          "qty": "4", "price": "63120" }
      ],
      "insuranceFundDelta": "0", "residualLoss": "0" }
  ],
  "asOfSeq": 104910, "ts": 1785000000800 }

The payload is asymmetric by design. As the DEFAULTER you see the full episode: every canceled order id, every trade id, all allocations, the insurance fund delta and any residual loss. As a COUNTERPARTY you see only your own allocations, with insuranceFundDelta and residualLoss reported as "0", because another member's default economics are not yours to read.

Stream recovery

Every event-class message the private WebSocket delivers is also written to a durable, sequence-ordered store and can be re-read over REST. Even a REST-only integration should page this at startup to prove that nothing happened while the process was down.

{ "code": 0, "msg": "ok",
  "data": {
    "headCursor": "000000000000010487000000000090", "headSeq": 104870,
    "retentionFromCursor": "000000000000009800000000000000", "retentionFromSeq": 98000,
    "store": { "contiguousThroughSeq": 104870, "engineSeq": 104882,
               "lagSeq": 12, "status": "CATCHING_UP", "complete": false }
  },
  "asOfSeq": 104870, "ts": 1785000000900 }

headCursor is the newest row visible to you at the watermark, omitted when you have none. retentionFromCursor is the oldest row still retained (default retention 35 days): if your stored cursor is older than that, a complete backfill is impossible and you must fall back to snapshot reads plus the dated history routes.

That 35 day window is the event stream's own retention. The venue's record of every transaction (orders, executions, ledger postings and the contract lifecycle) is kept for at least seven years from the creation of each record on a durable medium that keeps it unaltered and replayable, and it is available to you on request: use the history routes, the ledger and your monthly statements first, and for anything beyond them write to venue operations, which answers from the venue's archive with your own records only, never counterparty identities, within ten Business Days (revision 3.70).

Exactly one of afterCursor or fromSeq is required; supplying both or neither gives 5003 with a message naming the parameter. Ordering is strictly ascending by (seq, eventIndex, leg), the only ascending history route on the venue, because a backfill has to replay in engine order.

{ "code": 0, "msg": "ok",
  "data": {
    "fromCursor": "000000000000010486000000000040",
    "nextCursor": "000000000000010486800000000011",
    "hasMore": true, "count": 500,
    "events": [
      { "channel": "execution", "eventType": "EXECUTION", "asOfSeq": 104862,
        "eventIndex": 0, "leg": 1, "cursor": "000000000000010486200000000001",
        "data": { "tradeId": 55123, "orderId": 887711, "symbol": "BTC-USD-PERP",
                  "side": "BUY", "price": "65000", "qty": "5", "fee": "162.5",
                  "role": "TAKER", "flags": "NORMAL", "clOrdId": "a3f1c9d24b7e4f108c6d2e5b",
                  "clientUid": "CLIENT-A", "ts": 1785000000512 } } ],
    "store": { "contiguousThroughSeq": 104870, "engineSeq": 104882,
               "lagSeq": 12, "status": "CATCHING_UP", "complete": false }
  },
  "asOfSeq": 104870, "ts": 1785000001000 }

Page by feeding nextCursor back as afterCursor until hasMore is false, and stop on hasMore false or count 0, never on nextCursor equal to the afterCursor you sent. On a page with hasMore true nextCursor is the cursor of the last returned event; on a page with hasMore false (revision 3.73) it is a position at the store watermark the page was read at, or at your toSeq when that is lower (eventIndex 2147483647 and leg 9, a bound, not a delivery), never lower than your own cursor and valid only with the same channels and symbol, so a filter that matches nothing new advances instead of re-reading the same range. The venue serves that last-page position on an environment from the date venue operations announce for it there (revision 3.83 states the condition, which revision 3.73 left out); before that date, and on a page read while the store recorded or cleared a hole, a last page answers the cursor of its last event, else the cursor you sent, and the loop rule above is correct under both. Persist that nextCursor per filter and resume from the ordinal maximum of it and the cursor of the last event you processed. Reads are clamped at the watermark: no returned event ever carries an asOfSeq above store.contiguousThroughSeq, and nextCursor never passes it either. A page can therefore come back short of the engine head, but never out of order and never with a hole in it. store.status is an exhaustive three-value enum: COMPLETE (level with the engine), CATCHING_UP (poll again), REPAIRING (the store has a recorded hole and reads stall below it rather than skipping it, so keep polling and raise an operational alert). Because the live socket flush runs marginally ahead of the store write, a backfill issued microseconds after a live message can legitimately come back short with CATCHING_UP; that is what lagSeq and waitMs are for. On a deployment without an event store these three routes answer 5004 with HTTP 503 after authenticating, never a 404.

Reconciliation

date is required, in the form YYYY-MM-DD; a value that is no date gives 5003. Without format, or with any value other than csv, the response is the standard envelope with an array of {date, clientUid, symbol, positionSide, netQty, avgEntry, mark, upnl}: positionSide (LONG or SHORT) is omitted on netting rows, mark when the market had none and upnl when the row holds none. With format=csv the response is raw text/csv with no envelope, which is the one place on the API where that is true, so route it before your generic JSON parser:

date,clientUid,symbol,positionSide,netQty,avgEntry,mark,upnl
2026-10-18,CLIENT-A,BTC-USD-PERP,NET,4,64110.5,65001.25,3563
2026-10-18,CLIENT-B,ETH-USD-PERP,SHORT,-20,3210.25,3198.5,235
2026-10-18,"CL,C",BTC-USD-PERP,NET,0.5,65200,65001.25,

The CSV prints date as YYYY-MM-DD, positionSide as NET on netting rows and an absent value as an empty field, and quotes a field that holds a comma, a double quote, CR or LF per RFC 4180 (wrapped in double quotes, every inner quote doubled); nothing else is escaped, so a spreadsheet may evaluate a clientUid that begins with = or @. Before revision 3.81 the CSV printed date month first (MM/DD/YYYY), quoted no field and left upnl empty on every row.

upnl (revision 3.81) is the unrealized PnL at mark in the market's settlement currency, exact to the micro: the unrealizedPnl that GET /v1/positions/end-clients reports at that mark, computed from the booked cost basis, so it can differ by micros from netQty x (mark - avgEntry). The venue writes it only where the history store's net quantity for the row equalled the matching engine's at the snapshot's instant; otherwise (the third line above), without a mark, and on rows recorded before revision 3.81 it is empty in the CSV and omitted in JSON. Rows are immutable once written, and a day without a snapshot answers an empty list.

This is the end-of-day snapshot to diff against your own sub-position ledger. The venue takes it at its daily anchor, within about five minutes after 00:00 UTC for the day that just ended, while it keeps trading, so a fill of the first minutes of the new day can be in it. If the venue restarts, or another of its nodes takes over, before the next anchor, the anchor runs again for the previous day and adds the rows of the sub-positions that day does not hold yet, from the state at that moment, mark and upnl included (all of the day's rows when the anchor had not run at midnight); a snapshot venue operations take by hand does the same, and a row already written never changes. Run it daily: per-clientUid positions are informational at the venue and authoritative at your firm, and a silent divergence found a month later is a regulatory problem rather than a bug.

Market Segments

Market Segments is the venue's counterparty-acceptance mechanism. Matching requires mutual acceptance and the default is open to all. Restricted liquidity stays visible in the full book; the matchable book shows what you can actually hit.

GET/PUT /v1/eligibility and GET /v1/eligibility/matchable-members are compatibility aliases with identical handlers and payloads, kept for the life of /v1. Price-time priority is honoured within your accepted counterparty set: if better-priced liquidity exists from members outside your mutual acceptance, your order executes at the best price matchable for you, which is why a fill can print worse than the top of the full book.

Idempotency and safe retries

clOrdId is the idempotency key for order entry. The venue indexes it per member, and the three outcomes are exhaustive:

The duplicate response is the current state of the original order, not a replay of the original response, so a retry that lands after the order has filled returns FILLED with duplicate: true. Treat duplicate: true as success and reconcile against the returned orderId.

How long the venue holds a reference. Uniqueness for 24 hours is your obligation. What the venue retains is the most recent 4,000,000 references venue-wide, or 24 hours, whichever is reached first, so on a day of exceptional venue-wide volume the effective duplicate-detection horizon is shorter than 24 hours. A released reference is simply unknown, so the first row of the table above applies to it: a resend places a NEW order. A reference whose order is still working or pending trigger is never released, so DELETE /v1/orders?clOrdId= resolves for the whole life of the order. Retries act within seconds and are unaffected; reconcile older state by orderId or GET /v1/orders, never by resending.

Two things are never backfillable and must be handled synchronously: the duplicate rejection above (it reaches you only as the order response) and venueEvents frames (resubscribe and apply the fresh snapshot). Do not wait for either to appear in the event stream.

Errors and the retry matrix

The full registry, including every enumerated string value the API returns and the WebSocket close codes, is on the Reference page.

Integration checklist

Acceptance tests worth writing before you go live: the signature vector matches; a far-from-market LIMIT GTC comes back NEW and cancels to CANCELED with USER_REQUESTED and your identifiers echoed; an identical resend returns duplicate: true and the SAME orderId; the same reference with a changed payload returns 2009; an invented extra field returns 2017 naming the field; MARKET plus FOK larger than visible depth returns a single cancel with FOK_UNFILLABLE and zero partial fills; an unknown symbol returns 2001 with your clOrdId echoed; and your account parser survives both the array shape and the uppercase MM key.