Message shapes

Every server-to-client push uses the same canonical envelope:

{
  "type": "<event_type>",
  "sid": 12,
  "channel": "token_trade_matches",
  "id": "60550363974013526...",
  "serverTs": 1778783112456,
  "data": { ... }
}

Field	Meaning
`type`	Concrete event type (e.g. `trade_matched`, `trade_settled`, `book_snapshot`, `order_placed`)
`sid`	Connection-local subscription id you got from the `subscribed` response
`channel`	One of the channel names from the catalog
`id`	The entity the frame belongs to: token id, condition id, market symbol (lowercased), `<symbol>:<outcomeIndex>` (lowercased) on `market_price_tick`, instrument id (lowercased), vault address or `platform_status`. On the wallet-scoped channels (`user_orders`, `user_fills`) it is your wallet address, lowercased. The `all_*` channels use the frame’s token id, `global_activity` the trade id, `notifications` / `dispute_intent` / `bond_payout_credited` the notification, dispute-intent or challenge id, and `me_limits_invalidated` the transaction hash
`serverTs`	Server wall-clock at frame emission, ms since epoch. Present on every outbound frame — including `connected`, ACKs, errors, and pong. Use as an authoritative ordering anchor between events arriving on the two transports (the REST companion is the `X-Server-Time` header).
`seq`	Monotonic sequence number — present on `book_snapshot` / `book_update` / `book_delta` (a per-token counter). A jump greater than 1 on the same `id` means a frame was missed and the client should resync. Other event types omit it.
`hash`	Canonical 16-hex SHA-256 prefix of the book state on `book_snapshot` / `book_update`. The same hash is returned by `GET /api/markets/{symbol}/orderbook` — clients can compare WS view against REST snapshot to detect drift. `book_delta` deliberately omits the hash (a delta is a transformation, not a state snapshot).
`data`	Event-specific payload (see below). The trade frames and `book_snapshot` / `book_update` / `book_delta` identify the outcome by `tokenId` + `outcomeIndex`, and all of them except `book_delta` also carry `conditionId`; `ohlc_update` and `book_snapshot_failed` carry only `tokenId`. `trade_matched` also carries `marketSymbol`; for the others, resolve symbols through REST if needed. A timestamp in `data` is `tsMs` (number, ms since epoch) unless the channel’s table names another field; the on-chain vault frames, `trade_failed` and `me_limits_invalidated` carry none — use `serverTs` or, for vault frames, `blockNumber` / `logIndex`.

Use sid to route inside your client; use id to identify which specific subscribed entity the event belongs to.

Event catalog

`user_orders` (`/ws/user`, `id` = your wallet)

`type`	`data`
`order_placed`	`{ walletAddress, orderId, orderHash, clientOrderId?, outcomeIndex, price, side, status: "placed", source, tsMs, marketId, originalQuantity, orderType, timeInForce, placedAt }`
`order_cancelled`	`{ walletAddress, orderId, clientOrderId?, outcomeIndex, status: "cancelled", reason, publicMessage?, source, tsMs, marketId, originalQuantity?, remainingQty?, eventAt }` — includes an order the matching engine declined (`reason: "matcher_rejected"`); `clientOrderId`, `originalQuantity` and `remainingQty` can be missing when a resting order is cancelled by self-trade prevention
`order_rejected`	`{ walletAddress, orderId, status: "rejected", reason: "matcher_error", source, tsMs, eventAt }` — the order was accepted, then the call that hands it to the matching engine failed; its locked funds are released
`order_expired`	`{ walletAddress, orderId, outcomeIndex, status: "expired", publicMessage?, source, tsMs, marketId, originalQuantity, remainingQty, eventAt }`
`trade_failed`	`{ orderId, orderHash, reason, reasonText, txHash, tokenId?, marketId?, outcomeIndex? }` — on-chain settlement of a matched trade failed (sent to the taker). Here `orderId` is the taker order’s EIP-712 hash, not the server UUID; match it against `order_placed.orderHash`.

The gateway normalizes these frames to the fields above; a key with no value for an event is left out. marketId is the market symbol. originalQuantity is the order size as placed (on order_placed, order_cancelled and order_expired) and remainingQty the unfilled size when the order was cancelled or expired, both in shares (canonical decimal strings; a self-trade-prevention cancel can lack both). On a cancel or expiry, originalQuantity - remainingQty is what had filled when the order ended, not a final fill total. orderType is LIMIT / MARKET, timeInForce GTC / IOC / FOK, placedAt the time the exchange accepted the order, and eventAt the time of a cancel, expiry or rejection (ISO 8601) — order those frames by eventAt, since their tsMs is the send time. Key your order state by orderId / clientOrderId. trade_failed names the market in marketId when it can be resolved. The order_* frames are state-change notifications, one per transition of an order, not a snapshot of it: they carry no filledQty (a cancel or expiry gives only the size filled by then, as above), and their status is the event label, not the REST order status. For the current state read GET /api/orders/{id}; the field-by-field mapping is in user_orders frames vs REST order detail.

`user_fills` (`/ws/user`, `id` = your wallet)

`type`	`data`
`user_fill`	match-time notification (matcher) — `{ walletAddress, side: 'buy' \| 'sell', role?: 'maker' \| 'taker', marketId, tradeId, orderId, clientOrderId?, outcomeIndex, price, signedUserPrice?, quantity, source: 'matcher', tsMs }`. `role` is `maker` when your order was resting in the book and `taker` when it crossed it. `marketId` is the market symbol; there is no `tokenId` / `conditionId`. `signedUserPrice` is your leg’s on-chain settlement price (equal to `price` except on a cross-outcome `MINT` / `BURN` match, where it is your order’s signed limit). `fee` / `txHash` / `blockNumber` / on-chain `orderHash` are intentionally omitted; poll `GET /api/me/trades` for the post-settlement view with resolved fee. Full payload reference: user_fill.

`vault_positions` (`/ws/user`, `ids` = [your vault address])

`type`	`data`
`vault_position_balance_changed`	`{ vaultAddress, token, tokenId, balance, reason, txHash, blockNumber, logIndex }` — absolute post-change outcome-token (ERC-1155) balance of `tokenId` in the vault
`vault_position_split`	`{ vaultAddress, conditionId, amount, balanceAfter, txHash, blockNumber, logIndex }` — `balanceAfter` is the vault’s collateral balance after the split
`vault_positions_merged`	`{ vaultAddress, conditionId, amount, balanceAfter, txHash, blockNumber, logIndex }`
`vault_position_redeemed`	`{ vaultAddress, conditionId, payout, toVault, balanceAfter, txHash, blockNumber, logIndex }` — `payout` is the total collateral credited to the vault; the burned outcome-token balances arrive as `vault_position_balance_changed` frames with reason `REDM`

Amounts are base-unit integers as decimal strings. These frames carry no tsMs; order them by blockNumber / logIndex. vault_position_balance_changed.reason is the vault contract’s bytes4 tag, sent as hex ("0x53504c54" = SPLT). Values: SPLT (split), MERG (merge), INFL / OUTF (exchange moved tokens into / out of the vault on a fill), REDM (redeem), CONV (neg-risk conversion), EMER (emergency withdrawal). The list is open-ended; treat unknown tags as a generic balance change. Hex values: Server events.

`vault_activity` (`/ws/user`, `ids` = [your vault address])

`type`	`data`
`trade_fill`	`{ side, orderHash, txHash, blockNumber, makerVault, takerVault, makerWallet, takerWallet, makerAssetId, takerAssetId, makerAmount, takerAmount, fee }` — an on-chain `OrderFilled` event naming your vault. `side` is your vault’s place in that event (`maker` = the event is for your own order), not your trade role
`deposit_confirmed`	`{ vault, from, token, amount, balanceAfter, txHash, blockNumber, logIndex }`
`withdrawal_confirmed`	`{ vault, to, token, amount, balanceAfter, txHash, blockNumber, logIndex }`
`exchange_balance_synced`	platform balance updated for an on-chain vault movement — re-read `GET /api/me/balances`

The channel also carries the vault’s other on-chain events (erc1155_balance, position_split, positions_merged, position_redeemed, order_digest_invalidated, emergency_*). Every shape, and how trade_fill pairs maker and taker events: Server events.

`user_activity` (`/ws/user`, no `ids`)

`type`	`data`
`withdrawal_<state>`	`{ id, userWallet, amount, destination, status, txHash, refunded, createdAt, updatedAt }` — one frame per withdrawal status change (`requested`, `approved`, `flagged_for_review`, `submitted`, `cancelled`, `rejected`, `expired`, `failed`); the final confirmation arrives as `withdrawal_confirmed` on `vault_activity`
`vault_created`	`{ owner, vault, txHash }`
`user_paused` / `user_unpaused`	`{ user, untilBlock?, txHash, blockNumber }` — the exchange paused / unpaused trading for your wallet; `untilBlock` is a Unix time in seconds

It also repeats order and trade events in an unnormalized form; use user_orders / user_fills for those. For order sizes in particular, read originalQuantity / remainingQty on user_orders: the raw qty / remaining here are the event payload as written, and the same size can be spelled differently on two events ("40.000000" and "40").

`notifications` (`/ws/user`, no `ids`, `id` = notification id)

`type`	`data`
`notification`	`{ id, walletAddress, type, category, title, body, marketId?, marketSymbol?, payload, createdAt, tsMs }` — one frame per notification added to your wallet’s in-app notification feed; `data.type` is the kind (`ORDER_FILLED`, `DEPOSIT_CONFIRMED`, `MARKET_RESOLVED`, `MARKET_VOIDED`, …), `category` its preference item or `null`

The live side of the web app’s notification centre: display text, created according to the preferences set in the web app, best-effort and not re-sent after a disconnect. Use the typed channels above for trading and accounting state.

`dispute_intent` (`/ws/user`, `id` = dispute intent id)

`type`	`data`
`dispute_intent_submitted` / `dispute_intent_accepted` / `dispute_intent_rejected` / `dispute_intent_expired`	`{ id, walletAddress, marketSymbol, txHash?, status, challengeId?, rejectionReason?, expiresAt, createdAt, updatedAt, tsMs }` — `status` is `PENDING`, `ACCEPTED`, `REJECTED_RACE` or `EXPIRED`

Status changes of disputes filed from the PredictStreet web app. A challenge sent on-chain directly has no dispute intent, so API integrations normally see nothing here; follow GET /api/challenges?challengerWallet=<address> instead.

`bond_payout_credited` (`/ws/user`, `id` = challenge id)

`type`	`data`
`bond_payout_credited`	`{ walletAddress, amountUsdcRaw, bondUsdcRaw, rewardUsdcRaw?, sourceChallengeId, marketSymbol, creditedAt, tsMs }` — USDC base units as decimal strings

The bond of a challenge you raised was credited back (override: bond plus reward; void or emergency proposal clear: bond), and the amount is now claimable from pendingBondPayouts on the oracle with withdrawBondPayout(to). See Challenges.

`me_limits_invalidated` (`/ws/user`, `id` = transaction hash)

`type`	`data`
`me_limits_invalidated`	`{ walletAddress, reason, txHash }` — `reason`: `tier_changed`, `custom_caps_set`, `deposits_restricted`, `trading_restricted`, `withdrawals_restricted`

Your wallet’s on-chain deposit tier, caps or a deposit / trading / withdrawal restriction changed. The frame carries no values — re-read GET /api/me/deposit-limits. dispute_intent, bond_payout_credited and me_limits_invalidated take your wallet as the only id on an API-key socket ("ids": ["0x…"], the greeting’s walletAddress) and no ids on a JWT session. Full shapes and examples for all four channels: Server events.

`token_trade_matches` (`/ws/market`, `id` = `tokenId`)

`type`	`data`
`trade_matched`	`{ tokenId, conditionId, marketSymbol, outcomeIndex, takerOutcomeIndex, tradeId, price, quantity, side, source: "matcher", tsMs }`

Fires the moment the matcher prints a trade — fastest tape feed. On a binary market each trade is published on both outcome tokens (the NO frame at price 1 − p, same tradeId); if you subscribe to both, keep the frame whose outcomeIndex equals takerOutcomeIndex (or dedupe on tradeId) before counting trades or volume.

`token_trade_settlements` (`/ws/market`, `id` = `tokenId`)

`type`	`data`
`trade_settled`	`{ tokenId, conditionId, outcomeIndex, orderHash, txHash, blockNumber, price, quantity, side, source: "chain", tsMs }`

Fires when the platform indexes an on-chain OrderFilled event. The exchange emits one per filled order (each maker order and the taker order of a match), so one match produces several frames, each describing the order in orderHash. Use it for accounting-grade confirmations of your own orders, keyed by orderHash; don’t add the frames up as independent trades. Example:

{
  "type":    "trade_settled",
  "sid":     13,
  "channel": "token_trade_settlements",
  "id":      "12345...",
  "data": {
    "tokenId":      "12345...",
    "conditionId":  "0xabc...",
    "outcomeIndex": 0,
    "orderHash":    "0x84a930f9e902ae91...",
    "txHash":       "0xc01780b2c76494d8...",
    "blockNumber":  1234567,
    "price":        "0.52",
    "quantity":     "30",
    "side":         "buy",
    "source":       "chain",
    "tsMs":         1776949200000
  }
}

`token_book` (`/ws/market`, `id` = `tokenId`)

`type`	`data`
`book_snapshot`	`{ tokenId, conditionId, outcomeIndex, bids, asks, seq, tsMs }` — initial state on subscribe (depth 100)
`book_update`	`{ tokenId, conditionId, outcomeIndex, seq, prevSeq, bids, asks, tsMs }` — the whole book at `seq`: every resting price level on both sides, each `{ price, quantity, count }` (total size and number of orders at that price), not just the best bid and ask. Replaces your local book; it is not a delta (that is `book_delta`)
`book_delta`	`{ tokenId, outcomeIndex, seq, prevSeq, changes: { bids, asks }, tsMs }` — diff against `prevSeq`; each change is `{ action: "upsert" \| "remove", price, quantity, count }`. No `conditionId`. Only emitted when the gateway has contiguous local book state
`book_snapshot_failed`	`{ tokenId, reason: "snapshot_unavailable", retryable, subscriptionActive }` — snapshot fetch could not be completed (on subscribe or in response to `get_book_snapshot`). `retryable` is always `true`; `subscriptionActive` is `true` when the snapshot was requested under a `sid` (that subscription keeps streaming) and `false` for a `get_book_snapshot` sent with `ids` alone

seq is monotonically increasing. After subscribe the server pushes one book_snapshot (depth 100), then one book_update (the full state) per book change. Right after each book_update comes a book_delta for the same change, carrying the same seq and data.prevSeq; the delta is skipped when the gateway doesn’t hold the previous state, so it never sends a divergent delta. Apply one stream, not both: either book_update frames, or book_snapshot + book_delta frames. In either stream, a frame whose data.prevSeq differs from the last seq you applied means you missed a change. On such a gap, or when a market you’d expect to be active goes quiet, issue get_book_snapshot to force a fresh snapshot. See Reconnect — orderbook resync. What a book frame holds. book_update is not just the best bid and ask: it is the complete book after the change, every resting price level on both sides, aggregated per price. Levels whose total size is below a small dust threshold are left out of every book frame, the same filter the REST orderbook applies. book_snapshot is capped at 100 levels per side, but prices sit on a 0.01 grid, so a side never has more than 99 levels and a snapshot also carries the whole book. book_delta carries the same change as a diff. Apply book_update frames, or book_snapshot + book_delta frames, not both. Both book_snapshot and book_update envelopes carry a hash field (16-hex truncated SHA-256 over canonical (bids, asks) — price + quantity only, count excluded). The same hash function is applied to the REST orderbook response. A client that maintains its own book view can hash it the same way and compare against the envelope hash to detect drift between the WS-applied state and the authoritative server view. book_delta envelopes omit hash. To check the book after applying a delta, compare your hash with the hash of the book_update that has the same seq — it arrives just before the delta.

`token_ohlc` (`/ws/market`, `id` = `tokenId`)

`type`	`data`
`ohlc_update`	`{ interval: "s5", tokenId, time, open, high, low, close, volume, isClosed, tsMs }` — `time` is the bar’s start in Unix seconds; `open` … `volume` are JSON numbers. No `conditionId` / `outcomeIndex`: map them from the token id you subscribed to

Rolling 5-second candles built from the trade_matched tape, pushed whenever a trade prints inside the active window. isClosed: false while the bar is still accumulating; isClosed: true is the final tick of the bar.

`market_price_tick` (`/ws/market`, `id` = lowercased `<symbol>:<outcomeIndex>`)

`type`	`data`
`price_tick`	`{ symbol, outcomeIndex, ts, price }` — `price` is the outcome’s mark (the market’s `chances` value) as a decimal string; `ts` is the one-second bucket (ISO 8601)

The live edge of GET /api/markets/{symbol}/price-history: at most about one frame per second per outcome, only while the market is OPEN and only when the outcome’s best bid, best ask or last trade changed. No backfill — seed from ?range=live.

`all_trade_matches` / `all_trade_settlements` / `all_books` (`/ws/market`, no `ids`)

Channel	`type`
`all_trade_matches`	`trade_matched`, as on `token_trade_matches`
`all_trade_settlements`	`trade_settled`, as on `token_trade_settlements`
`all_books`	`book_update` and `book_delta`, as on `token_book` (no `book_snapshot`)

Firehoses of the per-token frames for every token on the platform, with the frame’s tokenId as id. all_trade_matches still carries two frames per binary trade, a connection that also holds the per-token channel gets each frame once per sid, and all_books is high-volume. Details: Server events.

`global_activity` (`/ws/market`, no `ids`, `id` = `tradeId`)

`type`	`data`
`global_activity`	`{ tradeId, marketSymbol, outcomeIndex, outcomeLabel?, outcomeDisplayLabel?, side, price, quantity, actorWallet?, actorUsername?, marketTitle?, marketQuestion?, groupItemTitle?, groupItemImageUrl?, eventId?, eventTitle?, eventImageUrl?, eventSlug?, marketSlug?, tokenId?, tsMs }`

One frame per matched trade platform-wide, in the taker’s view (their outcome, side and price), with market / event titles and the taker’s username attached when available. Seed from GET /api/activity/recent, which serves the same fields.

`condition_lifecycle` (`/ws/market`, `id` = `conditionId`)

`type`	`data`
`condition_trading_paused`	`{ conditionId, pauser, txHash, blockNumber, tsMs }` — trading on this condition was paused on-chain
`condition_trading_unpaused`	`{ conditionId, pauser, txHash, blockNumber, tsMs }` — trading on this condition was unpaused on-chain

These are the only frames on this channel. Nothing is pushed on subscribe, and resolution or status changes are not sent here. Subscribe to market_lifecycle (status_changed, market_resolved) for those, and read the current status from GET /api/markets/{slug}.

`market_lifecycle` (`/ws/market`, `id` = lowercased market `symbol`)

`type`	`data`
`status_changed`	`{ marketSymbol, fromStatus, toStatus, action?, txHash?, tsMs }` — one push per lifecycle transition
`market_disputed`	`{ marketSymbol, questionId, challengedBy?, challengedAt?, proposedOutcomeCode?, txHash?, tsMs }`
`market_resolved`	`{ marketSymbol, questionId, outcomeCode?, winnerIndex?, negRiskMarketId?, txHash?, tsMs }`
`crypto_window_opened`	`{ marketSymbol, questionId, price, decimals, observedAt, frozenAt, tsMs }` — crypto Up/Down windows only, once per window
`crypto_window_closed`	`{ marketSymbol, questionId, price, decimals, observedAt, closedAt, tsMs }` — crypto Up/Down windows only; the close price the settlement measured against the open. Best-effort: when published, it arrives before `market_resolved`, but a window can resolve without it

Keyed by the market symbol. It carries status, dispute and resolution; condition_lifecycle carries only the on-chain trading pause. Optional fields are omitted when absent rather than sent as null.

`crypto_price_tick` (`/ws/market`, `id` = lowercased `instrumentId`)

`type`	`data`
`crypto_price_tick`	`{ instrumentId, price, decimals, at, src? }`

The underlying-asset price for crypto markets, keyed by instrument (btc-usd). price is an unscaled integer as a decimal string — render as price / 10 ** decimals with a bigint or decimal helper. at is the observation time and the point’s x-coordinate; src is "datastreams" (~1/s live spot) or "candlestick" (~1/min candle close). See Crypto price feeds. Example:

{
  "type": "crypto_price_tick",
  "sid": 1,
  "channel": "crypto_price_tick",
  "id": "btc-usd",
  "serverTs": 1785346775266,
  "data": {
    "instrumentId": "BTC-USD",
    "price": "63755779816750000000000",
    "decimals": 18,
    "at": "2026-07-29T17:39:33.000Z",
    "src": "datastreams"
  }
}

`system` (`/ws/market`, `id` = `"platform_status"`)

`type`	`data`
`platform_status`	Reserved. The subscription is accepted, but no frames are published on this channel.

To detect a platform freeze, poll GET /api/platform/status, which returns { frozen, reason, since, activeNotices }.

Getting Started

Authentication

Vaults

Deposits

Trading

Events & Tags

Markets

Portfolio

Withdrawals

WebSocket

Settlement & Oracle

On-chain Contracts

Partners

Errors

Event catalog

`user_orders` (`/ws/user`, `id` = your wallet)

`user_fills` (`/ws/user`, `id` = your wallet)

`vault_positions` (`/ws/user`, `ids` = [your vault address])

`vault_activity` (`/ws/user`, `ids` = [your vault address])

`user_activity` (`/ws/user`, no `ids`)

`notifications` (`/ws/user`, no `ids`, `id` = notification id)

`dispute_intent` (`/ws/user`, `id` = dispute intent id)

`bond_payout_credited` (`/ws/user`, `id` = challenge id)

`me_limits_invalidated` (`/ws/user`, `id` = transaction hash)

`token_trade_matches` (`/ws/market`, `id` = `tokenId`)

`token_trade_settlements` (`/ws/market`, `id` = `tokenId`)

`token_book` (`/ws/market`, `id` = `tokenId`)

`token_ohlc` (`/ws/market`, `id` = `tokenId`)

`market_price_tick` (`/ws/market`, `id` = lowercased `<symbol>:<outcomeIndex>`)

`all_trade_matches` / `all_trade_settlements` / `all_books` (`/ws/market`, no `ids`)

`global_activity` (`/ws/market`, no `ids`, `id` = `tradeId`)

`condition_lifecycle` (`/ws/market`, `id` = `conditionId`)

`market_lifecycle` (`/ws/market`, `id` = lowercased market `symbol`)

`crypto_price_tick` (`/ws/market`, `id` = lowercased `instrumentId`)

`system` (`/ws/market`, `id` = `"platform_status"`)

​Event catalog

​user_orders (/ws/user, id = your wallet)

​user_fills (/ws/user, id = your wallet)

​vault_positions (/ws/user, ids = [your vault address])

​vault_activity (/ws/user, ids = [your vault address])

​user_activity (/ws/user, no ids)

​notifications (/ws/user, no ids, id = notification id)

​dispute_intent (/ws/user, id = dispute intent id)

​bond_payout_credited (/ws/user, id = challenge id)

​me_limits_invalidated (/ws/user, id = transaction hash)

​token_trade_matches (/ws/market, id = tokenId)

​token_trade_settlements (/ws/market, id = tokenId)

​token_book (/ws/market, id = tokenId)

​token_ohlc (/ws/market, id = tokenId)

​market_price_tick (/ws/market, id = lowercased <symbol>:<outcomeIndex>)

​all_trade_matches / all_trade_settlements / all_books (/ws/market, no ids)

​global_activity (/ws/market, no ids, id = tradeId)

​condition_lifecycle (/ws/market, id = conditionId)

​market_lifecycle (/ws/market, id = lowercased market symbol)

​crypto_price_tick (/ws/market, id = lowercased instrumentId)

​system (/ws/market, id = "platform_status")

Event catalog

`user_orders` (`/ws/user`, `id` = your wallet)

`user_fills` (`/ws/user`, `id` = your wallet)

`vault_positions` (`/ws/user`, `ids` = [your vault address])

`vault_activity` (`/ws/user`, `ids` = [your vault address])

`user_activity` (`/ws/user`, no `ids`)

`notifications` (`/ws/user`, no `ids`, `id` = notification id)

`dispute_intent` (`/ws/user`, `id` = dispute intent id)

`bond_payout_credited` (`/ws/user`, `id` = challenge id)

`me_limits_invalidated` (`/ws/user`, `id` = transaction hash)

`token_trade_matches` (`/ws/market`, `id` = `tokenId`)

`token_trade_settlements` (`/ws/market`, `id` = `tokenId`)

`token_book` (`/ws/market`, `id` = `tokenId`)

`token_ohlc` (`/ws/market`, `id` = `tokenId`)

`market_price_tick` (`/ws/market`, `id` = lowercased `<symbol>:<outcomeIndex>`)

`all_trade_matches` / `all_trade_settlements` / `all_books` (`/ws/market`, no `ids`)

`global_activity` (`/ws/market`, no `ids`, `id` = `tradeId`)

`condition_lifecycle` (`/ws/market`, `id` = `conditionId`)

`market_lifecycle` (`/ws/market`, `id` = lowercased market `symbol`)

`crypto_price_tick` (`/ws/market`, `id` = lowercased `instrumentId`)

`system` (`/ws/market`, `id` = `"platform_status"`)