Trade history of the key's party
Authorization
ApiKeyAuth In: header
Query Parameters
Maximum number of trades in the response (newest first). Without the parameter — the newest 100; the full history is NOT returned (hard cap 500).
1 <= value <= 500100Response 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" ] } }]{ "error": "string", "code": "INSUFFICIENT_FUNDS"}{ "error": "string", "code": "INSUFFICIENT_FUNDS"}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; so does rotating the key the socket opened with. The server pings every 30 s and drops a socket that missed the previous pong. While your socket is open you are online: takers can see and invite you (`GET /maker/status` → `invitable`). On connect the server immediately replays a SNAPSHOT of current state (`rfq.created` for every open RFQ the party is invited to, then `quote.created` + `quote.status` for the party's live quote on it) and streams live events afterwards. Clients do not need separate GET bootstrap calls: a reconnect IS a resync. Every message is JSON `{type, payload}`. Events are routed by party, so a bot that also takes sees its taker events here too: | type | payload | |---|---| | rfq.created | RfqDto — you were invited | | rfq.closed | {rfqId} — cancelled by the taker, or filled. With a live quote on it you also get `quote.status`: `lost` on a fill by another maker, `cancelled` on a cancel | | rfq.expired | {rfqId} — the deadline passed with no trade | | quote.created | QuoteDto — your quote was recorded; as taker, a quote on your RFQ went live (its allocations landed) | | quote.status | {quoteId, rfqId, status} — `won` / `lost` when the trade settles; `revoked` on re-quote, DELETE, a failed settlement or unsigned actions that expired; `cancelled` when the taker cancels; `expired` | | quote.anchored | {quoteId, rfqId, anchorCids} — the quote's allocations landed: it is live and visible to the taker | | trade.step | {tradeId, rfqId, step: "allocated", refs: [cid]} — every allocation of the trade is committed; the atomic settle follows | | trade.settled | TradeDto — settled atomically; `ledger` carries the proof | | trade.failed | {tradeId, rfqId, reason} — the settlement failed (the taker could not fund its leg, the window expired, or the maker's allocation is gone); nothing moved, the quote is revoked, the RFQ stays open until its deadline | | sign.requested | SignActionDto — an action now waits on your signature: one a call of yours returned, or one the desk queued for your accepted trade (see the signing rule above) | | sign.completed | {actionId} — the action left the queue: executed, expired or cancelled | | history.recorded | RfqHistoryDto — as taker: one of your RFQs closed without a trade | | resync | {} — server state was reset; reconnect for a fresh snapshot |
Accept a quote (taker) — atomic DvP settlement POST
Stages the trade — checks your funding and locks the quote — and answers **202** with `status: "settling"` plus `actions`: your own allocations to sign, one per instrument your legs touch (empty for a desk-signed house taker). Sign them all in one `POST /tx/execute`. One the desk could not queue at once follows as `sign.requested` (and in `GET /tx/pending`): until the outcome, sign what arrives for the trade. The desk adds its fee-receipt allocation and, once every allocation has landed, settles the trade in one transaction. The outcome arrives as `trade.settled` / `trade.failed` on the stream, or read it from `GET /trades` (settled) and `GET /rfq-history` (failed). A failed trade moves nothing; the quote is revoked and the RFQ stays open for another accept until its deadline. Unsigned allocations fail the trade about 11 minutes after the quote's `validUntil`; an action itself expires after 10, and until then the desk queues a fresh one in its place. An accept also drops any unsigned withdrawal of yours — or the maker's — in the trade's instruments, so it cannot spend the holdings the settlement needs: request it again after the outcome.