Venue capabilities

URL — No public environment serves this socket yet.

Topic venueCapability

Request parameters

Parameter	Type	Required	Description
`op`	string	Yes	`subscribe`
`reqId`	string	Yes	Echoed byte-exact on the answer. Printable ASCII, escape-free; anything else answers MALFORMED.
`params`	object	Yes
> `topics`	array of strings	Yes	`venueCapability`

Response parameters

Parameter	Type	Required	Description
`op`	string	Yes	One of `subscribe`, `unsubscribe`.
`reqId`	string	Yes	Echoed byte-exact on the answer. Printable ASCII, escape-free; anything else answers MALFORMED.
`success`	boolean	Yes	`true`

Push data parameters

The one organization-invariant channel: what a venue accepts is not a tenant’s business. timeInForce is the accepted set and postOnly the sub-list of those it is valid with. Absence is the negative throughout — an order type with no row is not accepted, and there is no accepted: false row to read.

What the image holds. The table this member enforces, one row per (exchange, instrumentType, orderType). It is this build’s configuration rather than platform state: it is fixed for the life of the process, so the image is the whole of it and a delta on this channel does not occur. It changes when a deployment does.

Parameter	Type	Required	Description
`event`	string	Yes	`venueCapability`
`msgType`	string	Yes	`venueCapability`
`topic`	string	Yes	`venueCapability`
`seq`	string	Yes	The stream position, as a decimal string — an int64 a JSON number would truncate.
`seqTs`	string	Yes	The stream timestamp, epoch-ns as a decimal string.
`isSnapshot`	boolean	Yes	One of `true`, `false`.
`snapshotId`	string	No	Present on a snapshot part only, and the same on every part of one image; the next image of any topic carries a different one. Opaque — compare it for equality and nothing else. It is not a sequence, a version or a timestamp, and its shape may change; a client that ordered by it would be relying on how a member happens to mint it. Use it to keep two images apart. A repeat `subscribe` re-pushes the image — that is the resync, and there is no separate op — so a client can start image N+1 while N is still arriving, and without a name on each part it cannot tell which `last: true` closes which, nor stop a straggling part of N landing in the map N+1 just cleared. Discard any part whose `snapshotId` is not the one you are currently applying.
`part`	integer	No	Present on a snapshot part only; 1-based.
`last`	boolean	No	Present on a snapshot part only. The image is complete when true — including for an empty channel, which is still one part.
`data`	array of objects	Yes	What a venue accepts, keyed by (`exchange`, `instrumentType`, `orderType`). A TRANSFORM of the owner’s flat table, not a restatement: the source is one entry per accepted combination, and the wire groups them so “which TIFs may I use here” is one lookup rather than a scan. Absence is the negative throughout — an order type with no row is not accepted, and there is no `accepted: false` row to read.
> `exchange`	string	Yes	A venue, by the platform’s own name for it — one vocabulary across every field named `exchange` on this wire (`accountRow`, `credentialRow`, `venueCapabilityRow`) and the same one the HTTP lane serves. Join these fields whole-string; they will agree. The market-type split is part of the name and is load-bearing. A venue’s spot and derivatives markets are separate venues here, with separate credentials, accounts and capability rows — `binance_spot` and `binance_usd-m` are two values, not one venue with an attribute, and collapsing them would let an order-form offer a spot account a contract it cannot hold. The set is open, and that is deliberate. These are reference-data rows, not a published enum: the platform lists a new venue by carrying a row, not by cutting a release, so a value you have not seen is a venue that was added — not an error and not a version mismatch. The members below are what the platform carries today, and the list is informative. Treat an unknown value as an opaque key: display it, join on it, and do not branch on it.
> `instrumentType`	string	Yes	One of `UNKNOWN`, `SPOT`, `FUTURES`, `INVERSE_FUTURES`, `QUANTO_FUTURES`, `PERPETUAL_SWAP`, `INVERSE_PERPETUAL_SWAP`, `QUANTO_PERPETUAL_SWAP`, `OPTION`, `INVERSE_OPTION`, `INDEX`.
> `orderType`	string	Yes	One of `UNKNOWN`, `LIMIT`, `MARKET`.
> `timeInForce`	array of strings	Yes	The accepted set for this combination.
> `postOnly`	array of strings	Yes	The sub-list of `timeInForce` that postOnly is valid with.
> `reduceOnly`	boolean	Yes	Present and false, never absent. False is the truth today — v1 refuses reduceOnly outright — and a field already on the wire flips to true additively when a venue earns it, where an absent field appearing later is a shape change.