Cessio Docs
ReferenceMakerTrades

Trade history of the key's party

GET
/maker/trades

Authorization

ApiKeyAuth
X-API-Key<token>

In: header

Query Parameters

limit?integer

Maximum number of trades in the response (newest first). Without the parameter — the newest 100; the full history is NOT returned (hard cap 500).

Range1 <= value <= 500
Default100

Response Body

application/json

application/json

application/json

curl -X GET "https://example.com/maker/trades"
[  {    "tradeId": "string",    "taker": "string",    "maker": "string",    "direction": "SELL",    "qty": "string",    "base": "cbtc",    "quote": "usdcx",    "price": "string",    "fee": "string",    "settledAt": "string",    "status": "settled",    "ledger": {      "updateId": "string",      "receiptCids": [        "string"      ]    }  }]

Maker live stream (WebSocket) GET

This is a WebSocket endpoint at `wss://<host>/maker/stream`. Authenticate the upgrade request with `X-API-Key`, for example with the Node `ws` package: `new WebSocket(url, { headers: { "X-API-Key": key } })`. Browser-native WebSocket cannot set upgrade headers and therefore is not a maker authentication client. A missing or unknown key closes the connection with code 4401 before any subscription. On connect the server immediately replays a SNAPSHOT of current state (`rfq.created` for every active RFQ the party is invited to, then `quote.created` + `quote.status` for the party's active quotes) and streams live events afterwards. Clients do not need separate GET bootstrap calls: a reconnect IS a resync. Every message is JSON `{type, payload}`: | type | payload | |---|---| | rfq.created | RfqDto | | rfq.closed | {rfqId} — cancelled or filled (indistinguishable to a maker) | | rfq.expired | {rfqId} | | quote.created | QuoteDto | | quote.status | {quoteId, rfqId, status: pending/won/lost/expired/revoked} | | quote.anchored | {quoteId, rfqId, proposalCid} — a passkey maker's proposal pair got signed, the quote is anchored | | trade.step | {tradeId, rfqId, step: trade_dvp/fee_dvp/allocated, refs: [cid]} — live per-phase settlement progress on the ledger | | trade.settled | TradeDto | | trade.failed | {tradeId, rfqId, reason} — settlement failed (underfunding, expired Dvp window) | | balances.updated | BalancesDto | | resync | {} — server state was reset; reconnect or wait for the snapshot |

Accept a quote (taker) — atomic DvP settlement POST

Consumes the maker's on-ledger DvpProposal pair, allocates both legs and settles the swap atomically. The synchronous path returns the settled trade; when a party's signature must ride the sign queue the desk answers **202** with `status: "settling"` and the outcome arrives later (`trade.settled` / `trade.failed` on the WebSocket, or poll `GET /trades` / `GET /rfq-history`).