--- title: Discovering Markets description: Read markets from the market catalog, view their trade history, and read their order books. --- Public REST market data needs no authentication. If you sign these requests anyway, they count against your member's `read` bucket instead of the shared public limit; see [Rate Limits](/reference/rate-limits). WebSocket market data requires authenticating with an API key that has the `read` scope. Discover a market's `ticker` through REST first, then subscribe to it over WebSocket: every subscribe command addresses a market only by the ticker the catalog gave you. ## Read the Catalog **REST** - [`GET /markets`](/api-reference/rest/markets/list-markets) returns single-leg and multi-leg markets. Use `type=single_leg` or `type=multi_leg` to select one; omit the filter to include both. Narrow the list further with `status`, `ticker`, `series_ticker`, or `event_ticker`: repeat `status` or `ticker` to match any of several values, and a market must match every filter you give. - [`GET /markets/{ticker}`](/api-reference/rest/markets/get-market) returns either by ticker. - [`GET /markets/{ticker}/trades`](/api-reference/rest/markets/get-market-trades) returns executed trades over a time range. - [`GET /markets/{ticker}/candlesticks`](/api-reference/rest/markets/get-market-candlesticks) returns OHLC aggregates per period over a time range. Single-leg markets omit `legs`. Multi-leg markets include at least two entries in `legs`, each with a `ticker` and selected `outcome` (`yes` or `no`). **WebSocket** The WebSocket API has no catalog read. Read the catalog over REST, then keep it current with the `market_lifecycle` stream described under [Follow Catalog Changes](#follow-catalog-changes). ## Read an Order Book **REST** [`GET /markets/{ticker}/orderbook`](/api-reference/rest/markets/get-market-orderbook) returns the current L2 book as a point-in-time snapshot. To read several books in one request, repeat `ticker` on [`GET /orderbooks`](/api-reference/rest/markets/list-orderbooks); it returns one book per market, ordered by ticker. **WebSocket** [`subscribe`](/api-reference/websocket/subscriptions/receive-subscribe-command) opens an `orderbook` subscription per ticker. Select `L1` for the best bid and offer, omit `level` for aggregated `L2`, or select `L3` for anonymous orders in price-time priority. The [`orderbook`](/api-reference/websocket/market-data/send-orderbook-data) stream starts with a snapshot, followed by sequenced updates; use [`snapshot`](/api-reference/websocket/subscriptions/receive-snapshot-command) to re-baseline after a sequence gap. ## Read a Market's Stats **REST** [`GET /markets/{ticker}/stats`](/api-reference/rest/markets/get-market-stats) returns the market's open interest, last price, and day and lifetime trading activity. **WebSocket** [`subscribe`](/api-reference/websocket/subscriptions/receive-subscribe-command) opens a `stats` subscription per ticker; `tickers` is required. The [`stats`](/api-reference/websocket/market-data/send-stats-data) stream sends the market's complete open interest, last price, and day figures on subscribe and again whenever they change, so each frame replaces the last and no `snapshot` command is needed. Lifetime figures are not streamed; read them over REST. ## Follow Trades **REST** [`GET /markets/{ticker}/trades`](/api-reference/rest/markets/get-market-trades) lists one market's trades and [`GET /trades`](/api-reference/rest/markets/list-trades) lists every market's. To keep a tape current, re-read in ascending order from the last `executed_at` you hold. A trade the exchange has voided is absent from the next read. **WebSocket** The `trades` channel is change-only, so establish and maintain a tape in this order: 1. Send [`subscribe`](/api-reference/websocket/subscriptions/receive-subscribe-command) for the `trades` channel. Omit `tickers` for every market, or list tickers to open one subscription each. 2. Wait for the `subscribed` acknowledgment, then read [`GET /trades`](/api-reference/rest/markets/list-trades) over REST to establish your starting state. 3. Apply each [`trade`](/api-reference/websocket/market-data/send-trade-data) frame in `seq` order. A `trade_busted` frame names a trade the exchange voided after it was delivered; remove it. 4. If you detect a `seq` gap, re-read `GET /trades` over REST in ascending order from your last `executed_at`. The channel has no snapshot, so the [`snapshot`](/api-reference/websocket/subscriptions/receive-snapshot-command) command is not accepted for it. ## Follow Catalog Changes **REST** REST has no push channel. Re-read [`GET /markets`](/api-reference/rest/markets/list-markets) on your own schedule, and compare each market's `status` and public details with your local copy. **WebSocket** The WebSocket API has no catalog-read operation, and REST has no push channel. The `market_lifecycle` channel is change-only, so establish and maintain your catalog in this order: 1. Send [`subscribe`](/api-reference/websocket/subscriptions/receive-subscribe-command) for the `market_lifecycle` channel. Omit `tickers` for every published market, or list tickers to open one subscription each. 2. Wait for the `subscribed` acknowledgment, then read [`GET /markets`](/api-reference/rest/markets/list-markets) over REST to establish your starting state. 3. Apply each [`market_lifecycle`](/api-reference/websocket/market-lifecycle/send-market-lifecycle-data) frame in `seq` order. Each change carries the full market under `msg.market`: `market_created`, `market_opened`, `market_paused`, `market_closed`, `market_expired`, `market_deleted`, or `market_metadata_updated`. 4. If you detect a `seq` gap, re-read `GET /markets` over REST to rebuild the catalog. ## Reconnect a Session Over WebSocket, subscriptions and sequence numbers do not survive a closed connection, and nothing is replayed after a reconnect. Whatever closed the connection, recover the same way: reconnect with a new signature, create new subscriptions, rebuild every order book from its new initial snapshot, and re-read the catalog over REST.