Subscriptions & markets

A subscription is one (market, channel) pair on a connection. You create them with SUBSCRIBE, name the market with a MarketStream, and the server hands back a subscriptionId that keys every frame that follows.

`MarketStream`

How you reference a market on the wire. It’s a discriminated union on venue. You build it from venue-native identifiers you already have, or that you get from the Markets API or the venue’s List Markets.

{
  "venue": "POLYMARKET",
  "tokenId": "71045620195867637"
}

{
  "venue": "KALSHI",
  "ticker": "KXNBA-25-LAL"
}

{
  "venue": "PROPHETX",
  "strikeId": "ab39fb9a7b4eb6a26d7e26f885c601c1"
}

{
  "venue": "LIMITLESS",
  "kind": "CLOB",
  "marketId": "btc-100k-weekly",
  "outcomeId": "84329471234058196"
}

Field	Venue	Meaning
`tokenId`	polymarket	ERC-1155 token id of the side you want. Already side-specific, so no separate outcome field is needed. The Markets API returns this as the listing’s `tokenId`.
`ticker`	kalshi	Market ticker, exactly as Kalshi publishes it. It addresses the market’s single orderbook, so no outcome field is needed. Tickers are case-sensitive and are not upcased for you.
`side`	kalshi	Optional, and only `"YES"` is accepted. Omitting it is identical to sending `"YES"`. A subscribe naming `"no"` is refused. See the note below.
`strikeId`	prophetx	The strike, which names the market and the outcome at once, so no outcome field is needed. List Event Markets returns it on each ProphetX listing, and it is the same id you trade.
`kind`	limitless	`"CLOB"`, the only kind the stream supports. `"AMM"` is accepted by the schema, but an AMM subscription is refused with an `UNKNOWN_MARKET` error that ends it, whether or not a `SUBSCRIBED` ack has already arrived.
`marketId`	limitless	Market slug.
`outcomeId`	limitless	Outcome token id of the side you want: the `tokenId` of the chosen entry in the market’s `outcomes` from List Markets. Must be one of the slug’s two outcome tokens; anything else is rejected with `UNKNOWN_MARKET`.

How many entries a market takes

Venue	Entries per market
Polymarket	One per outcome. A `tokenId` is already outcome-specific, so YES and NO are two entries. Subscribe to either or both.
Kalshi	One per market. The ticker is a single YES-priced book, and only the `YES` side is subscribable.
ProphetX	One per outcome. A `strikeId` names the market and the outcome at once, and the opposite outcome is a different strike with its own id, streamed in its own frames. Subscribe to either or both.
Limitless	One per outcome. One slug covers both sides, and you name the side with `outcomeId`. The two are views of one shared orderbook, the NO book being the exact complement of the YES book; subscribe to either or both, and both stream accurately.

Kalshi works differently: one ticker, one book, one subscribable side. Where the other venues give you an entry per outcome and you pick either or both, a Kalshi ticker addresses a single YES-priced orderbook and there is no second entry to subscribe to. side accepts only "YES"; a subscribe naming "no" is refused with UNKNOWN_MARKET rather than returning a NO feed. You read the NO side by deriving it locally. See below.side: "YES" and an omitted side name the same subscription. Sending both forms on one connection does not create two: the second returns the existing subscriptionId, under the idempotency rule described in SUBSCRIBE.

Deriving the NO side of a Kalshi market

The book we publish is YES-priced. The NO side is that same book read from the other end, which you compute locally. Two transforms, and you need both: applying 1 - price without swapping the sides produces a plausible book that is wrong:

Price becomes 1 - price.
Sides swap. Our asks are your NO bids; our bids are your NO asks.
Size carries across unchanged. One contract is one contract read from either end: buying NO at 0.47 and selling YES at 0.53 move the same single contract, so only the price coordinate and the bid/ask label flip. size is in shares, not notional, so it never scales by price.
Re-sort afterwards. Our bids are ordered best first (descending price) and our asks best first (ascending price), and 1 - price reverses both orderings.

Given this SNAPSHOT for { "venue": "KALSHI", "ticker": "KXNBA-25-LAL" }:

{
  "bids": [ { "price": 0.52, "size": 1250 }, { "price": 0.51, "size": 900 } ],
  "asks": [ { "price": 0.53, "size": 800 }, { "price": 0.54, "size": 1500 } ]
}

the NO view is:

NO side	`price`	`size`	Derived from
bid	0.47	800	our `asks[0]`, `1 - 0.53`
bid	0.46	1500	our `asks[1]`, `1 - 0.54`
ask	0.48	1250	our `bids[0]`, `1 - 0.52`
ask	0.49	900	our `bids[1]`, `1 - 0.51`

Three checks to assert against your own implementation:

YES best ask 0.53 + NO best bid 0.47 = 1.00
YES best bid 0.52 + NO best ask 0.48 = 1.00
The spread is preserved: 0.01 in both views.

DELTA frames derive the same way, side included:

{ "side": "BID", "price": 0.52, "size": 0 }
{ "side": "ASK", "price": 0.48, "size": 0 }

The first is what we send; the second is that same change in the NO view. size: 0 still deletes the level.

Channels

Channel	Venues	Delivers
`BOOK`	Polymarket, Kalshi, ProphetX, Limitless	`SNAPSHOT` then `DELTA` frames: the orderbook. This is the default when `channels` is omitted.
`TRADE`	Polymarket, Kalshi, ProphetX	`TRADE` frames: the market’s public trade tape, one frame per fill, from the moment you subscribe. Limitless does not publish a public trade feed, so a `TRADE` subscribe on a Limitless market is rejected with `UNSUPPORTED_CHANNEL`.

A subscription is one (market, channel) pair. Subscribing to one market on both channels counts as two subscriptions against the per-connection cap.

{
  "type": "SUBSCRIBE",
  "markets": [ { "venue": "POLYMARKET", "tokenId": "71045620195867637" } ],
  "channels": ["BOOK"],
  "requestId": "01HZX0RJQ4Z6K7Y9V2N0WP3M8C"
}

Field	Required	Notes
`markets`	yes	Array of `MarketStream`. Each entry gets a `SUBSCRIBED` ack or an `ERROR`, and a `SUBSCRIBED` can later be followed by an `ERROR` that ends it.
`channels`	no	Defaults to `["BOOK"]`.
`requestId`	no	Echoed on connection-level error replies for this call.

For each market in the batch you get back a SUBSCRIBED ack or an ERROR (for example, UNKNOWN_MARKET), so a market the server cannot resolve never sinks the rest of the batch. SUBSCRIBED is sent before the upstream venue feed has confirmed the market. If the feed then refuses it or does not confirm it in time, or a book’s first snapshot never arrives, a later ERROR carrying the subscriptionId ends the subscription, so one market can get a SUBSCRIBED followed by an ERROR. See ERROR. A frame that fails validation is different: the whole frame is rejected before any market is read, so a malformed entry takes its batch with it.

{
  "type": "SUBSCRIBED",
  "v": 1,
  "serverTimestamp": 1748020034200,
  "market": { "venue": "POLYMARKET", "tokenId": "71045620195867637" },
  "channel": "BOOK",
  "subscriptionId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "snapshotPending": true
}

Cache the mapping from subscriptionId to whatever local state you keep for that market. Every subsequent frame for this subscription is keyed by that id, and it’s also the handle you pass to UNSUBSCRIBE. snapshotPending: true tells you a SNAPSHOT is on its way (it is always false on the trade channel, since the tape has no snapshot). Subscribing is idempotent per (connection, market, channel): a repeat returns the existing subscriptionId rather than creating a second one.

`UNSUBSCRIBE`

{ "type": "UNSUBSCRIBE", "subscriptionIds": ["f47ac10b-58cc-4372-a567-0e02b2c3d479"], "requestId": "…" }

Unsubscribe by the subscriptionId(s) from prior SUBSCRIBED acks. Each id this connection still holds gets an UNSUBSCRIBED reply, carrying subscriptionId, market, and channel. An id the connection does not hold, because it is unknown or the subscription was already removed (by an earlier UNSUBSCRIBE, an ERROR that ended it, or a CLOSED status), is ignored with no reply. A frame that names only such ids gets no reply at all.

`LIST`

{ "type": "LIST", "requestId": "…" }

Returns a SUBSCRIPTIONS frame: one atomic snapshot of every active subscription on this connection.

Get started

Connecting

Market data

Reference

Subscriptions & markets

`MarketStream`

How many entries a market takes

Deriving the NO side of a Kalshi market

Channels

`UNSUBSCRIBE`

`LIST`

​MarketStream

​How many entries a market takes

​Deriving the NO side of a Kalshi market

​Channels

​SUBSCRIBE

​UNSUBSCRIBE

​LIST

`MarketStream`

How many entries a market takes

Deriving the NO side of a Kalshi market

Channels

`SUBSCRIBE`

`UNSUBSCRIBE`

`LIST`