Options Data Collection

This guide is for anyone building a market data pipeline against Deribit options — quants backfilling historical IV surfaces, market makers streaming live order books, or risk teams tracking greeks and mark prices across an option chain. It focuses on what’s specific to options: which channel or method covers greeks, IV, combos, and settlement, and how option instruments behave differently from futures and perpetuals when collecting data. For general WebSocket/REST tradeoffs, subscription patterns, and connection handling that apply across all instrument kinds, see the articles linked throughout this guide.

​

Discover and track the option chain

Don’t rebuild the instrument list from scratch on every run:

1. On startup, call public/get_instruments with currency=BTC and kind=option once to seed your local instrument set.
2. From then on, track changes via the instrument.creation.{kind}.{currency} and instrument.state.{kind}.{currency} channels instead of re-polling — see Market Data Collection - Best Practices for how the lifecycle states work.

Each option instrument also carries an expiration_timestamp. Precompute expiries locally from the seeded instrument list rather than deriving them by parsing instrument names — the option_type (call/put) and strike fields are also provided directly on each instrument record.

​

Order books

Two channels cover order book depth, with a real bandwidth/completeness tradeoff: For a full option chain (dozens to hundreds of instruments per expiry), the grouped channel is usually the right default — subscribing to full-depth raw books on every strike/expiry combination multiplies message volume unnecessarily, and the narrow-vs-wide subscription tradeoffs apply just as much across strikes as they do across currencies. For how to maintain book state correctly across snapshots, incremental updates, and change_id/prev_change_id gap detection, see Notifications - Order Book Notifications. The same mechanics apply to option order books; option instrument names just look like BTC-27JUL26-70000-C instead of BTC-PERPETUAL. As with other instruments, the raw interval is only available on authenticated connections — use 100ms or agg2 on public connections.

​

Ticker, greeks, and implied volatility

ticker.{instrument_name}.{interval} streams the full ticker payload per instrument — including mark_price, mark_iv, bid_iv, ask_iv, and the full greeks object (delta, gamma, theta, vega, rho) for options. For a chain with many strikes, prefer incremental_ticker.{instrument_name} where available — it only pushes fields that changed since the last update, reducing bandwidth versus the full-payload channel when you’re tracking many instruments at once. incremental_ticker is capped at one update per second per instrument, so if you need sub-second ticker precision on a small number of instruments, use the full ticker.{instrument_name}.{interval} channel instead. If all you need is the current spread — best bid/ask price and size, no greeks, no full book — quote.{instrument_name} is lighter than either ticker channel and avoids the cost of tracking book state entirely. For a whole-chain view of mark prices and IV without subscribing to every instrument individually, use markprice.options.{index_name} — it streams mark price and mark IV updates for every option under that index in one channel. This is the most efficient way to track valuation across an entire option chain in real time (portfolio marking, P&L, risk dashboards). If you only need a periodic full-chain snapshot rather than a continuous stream — for example to validate your WebSocket-derived state, or to seed a new pipeline — public/get_book_summary_by_currency with kind=option returns mark price, IV, volume, and open interest for every option in one REST call. Use it for point-in-time reconciliation, not as a substitute for the streaming channels.

​

Historical and realized/implied volatility

• public/get_historical_volatility — realized volatility time series for a currency, useful as a model input or a sanity check against streamed mark_iv.
• deribit_volatility_index.{index_name} (WebSocket) and public/get_volatility_index_data (REST, candle-formatted) — Deribit’s DVOL index, an expectation of forward volatility analogous to VIX. Use the WebSocket channel for live DVOL, the REST method for backfilling DVOL history.

​

Trades

As with order books, prefer the per-currency+kind channel (trades.option.BTC.raw, for example) over one subscription per instrument when you’re covering a full chain — see Subscription Strategies and Filters for the general tradeoff. It scales far better as new strikes and expiries are listed, since you don’t need to manage per-instrument subscriptions as the chain changes. For REST backfill, count is capped at 1000 per call on both trade-history methods — see Pagination patterns at a glance below for how to page through a full history without gaps or duplicates. Sequence-based pagination (start_seq/end_seq) is preferable when you need a gapless history, since it isn’t affected by multiple trades sharing a timestamp.

​

Multi-leg strategies (combos)

Combo (multi-leg option spread) books are a separate object from individual option instruments:

• public/get_combo_ids — list combo IDs for a currency (optionally filtered by state).
• public/get_combos — active combos with full leg structure for a currency.
• public/get_combo_details — full detail for one combo ID.
• user.combo_trades.{instrument_name}.{interval} / user.combo_trades.{kind}.{currency}.{interval} — trade prints for combo instruments (requires the private/authenticated connection scope, since these are user-trade channels).

If your pipeline needs to track combo books alongside single-leg instruments, treat combo IDs as their own instrument namespace — they aren’t returned by public/get_instruments with kind=option.

​

Settlement and expiration data

• public/get_delivery_prices — historical settlement/delivery prices for an index, paginated via offset/count (max 1000 per page). Use this for backtesting how options actually settled.
• estimated_expiration_price.{index_name} (WebSocket) — live estimate of the price that will be used at the next settlement, useful for monitoring expected settlement levels intraday as expiry approaches.

​

Pagination patterns at a glance

Different endpoints paginate differently — matching the right pattern to the right endpoint avoids gaps or duplicate records in backfilled data: count parameters across these methods cap at 1000 per request — always loop until a page returns fewer than the requested count (or an empty continuation) rather than assuming one call is exhaustive.

​

Summary checklist