Market by order

Order-level market data on mbo:{market_id} — rests, cancels, reductions and trades, anonymized.

Level-2 depth tells you how much size sits at each price. Market by order tells you what each individual order in the queue is doing: when one arrives, when it leaves, when it shrinks, and when it trades. That is what you need to model queue position, measure how long liquidity actually rests, and separate one large order from ten small ones at the same level.

Subscribe to mbo:{market_id} alongside the channels you already use — it does not replace orderbook: or trades:, it explains them.

{ "type": "subscribe", "channels": ["mbo:018f2c1a-…"] }

Who can subscribe

mbo: is a premium feed channel, gated the same way full-depth orderbook: and the trades: tape are: an API-key client needs the premium feed tier. See Limits & retention for how the tiers are applied.

The commercial rule is tier OR the data:live data-product entitlement — a key that holds data:live reaches the feed regardless of its rate-limit tier, because an entitlement is additive and never restrictive.

Honest current state. Both halves are live: a key reaches mbo: on the ENTERPRISE tier or by holding data:live. Entitlements are not self-serve — an admin grants them against a signed data licence, so a key you mint yourself carries none. See Data products.

Events

Every frame rides the standard envelope ({type, channel, data, ts, sequence}) documented in Connect & authenticate. Prices and sizes are decimal strings.

EventMeaning
mbo_addAn order came to rest on the book at price for size.
mbo_cancelAn order left the book; canceled_size is the remaining size removed from the level.
mbo_reduceA resting order shrank in place, keeping its queue priority. remaining_size is the new absolute size, not a delta.
mbo_tradeA trade executed against a resting order. maker_ref is the order that was hit; taker_side is the aggressor’s direction.

A reprice or size increase is not an mbo_reduce. Those lose queue priority, so they appear the way the book experiences them: an mbo_cancel followed by an mbo_add carrying a new order_ref. A size decrease keeps the same reference because the order keeps its place in the queue.

mbo_trade.maker_ref is null when a fill had no resting counterparty (it executed against AMM liquidity). sequence_number is the trade’s tape sequence, so a frame joins directly to the matching public trade print on trades:{market_id}.

{
  "type": "mbo_add",
  "channel": "mbo:018f2c1a-…",
  "data": {
    "market_id": "018f2c1a-…",
    "outcome_id": "018f2c2b-…",
    "order_ref": "9f2b7c41a03d58e6",
    "side": "BUY",
    "price": "0.6100",
    "size": "500.0000",
    "ts": "2026-07-29T14:03:11.482911+00:00"
  },
  "ts": 1785074591.48,
  "sequence": 91423
}

Anonymization

No frame on this channel identifies a trader. There is no user id, no account, and no order id — only order_ref (and maker_ref on a trade), which is a keyed hash, not an encoding:

  • Stable within a UTC day. The same order keeps the same reference all day, which is what makes queue tracking possible.
  • Rotated every UTC midnight. The same order gets a different reference tomorrow, so behaviour cannot be followed across days.
  • Scoped per market. The same order can never be correlated between markets.
  • Irreversible. It is derived with a server-side secret; a reference cannot be turned back into an order.

Build your intra-day models against the reference, and treat a new day as a fresh set of identifiers.

History and retention

This feed is live-forward only. It streams what happens from the moment you subscribe. There is no historical MBO reconstruction and no order-book ladder history to replay — we do not offer one because the stored data cannot honestly back it, and reconstructing a book from incomplete records would mean inventing states that never existed.

Retention follows the standard ephemeral contract, the same as orderbook:: frames carry per-channel sequence numbers, a gap is closed with a paginated resync inside the standard window, and frames may be shed to a slow consumer under backpressure rather than queued indefinitely. See Sequencing & replay and Limits & retention.

For historical analysis, use the trade tape (GET /trades/cursor walks it gap-free by sequence) rather than this channel.

Availability

The feed is enabled per environment. On staging it is on, so you can build and test against paper-market activity with a drzl_test_ key on the premium tier. If a market’s mbo: channel accepts your subscription but sends nothing, the feed is not enabled in that environment — the subscription is valid either way, so your client needs no special handling.