Cessio Docs
ReferenceMakerStatus

Can I trade right now?

The preconditions a bot can otherwise only discover by never being invited. Doubles as an API-key validity check. Answered from the desk's memory, so it is cheap — still, a startup check and one after an error burst are all a bot needs.

GET
/maker/status

The preconditions a bot can otherwise only discover by never being invited. Doubles as an API-key validity check. Answered from the desk's memory, so it is cheap — still, a startup check and one after an error burst are all a bot needs.

Authorization

ApiKeyAuth
X-API-Key<token>

In: header

Response Body

application/json

application/json

curl -X GET "https://example.com/maker/status"
{  "partyId": "string",  "hint": "acme-mm-a1b2c3",  "invitable": true,  "pendingActions": 0}

Start self-serve maker registration (headless bot) POST

No API key needed — this is how a maker gets one. Generates a fresh Canton party hosted on the desk's participant plus the topology transactions authorizing it; the caller signs `topology[].hash` (the RAW bytes, not the base64 text) with the Ed25519 key that will become the party's signing key, then calls `POST /maker/register/complete` with the signature(s) in the same order. The pending registration expires after 10 minutes.

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 |