Product roadmap

This request is to make the API documentation available for download so it can be referenced offline.

Currently, indices are indirectly supported through tradable index instruments on CME futures, ETFs, etc. and we don't provide the index values (non-tradable) themselves. This may be sourced from a feed like the Cboe Global Indices Feed or NYSE Global Index Feed.

Full depth of book feed for Cboe Futures Exchange (CFE). CFE contains volatility futures and corporate bond index futures, such as VIX futures (VX, VXM).

To extend support to browser-based applications.

This client library makes all our historical and live features easier to integrate in C# on Windows, Linux, and Mac OS. C# is currently already supported through our HTTP API and Raw TCP protocol, which are both language-agnostic.

For ICE US futures including US softs and financials, such as cocoa, cotton, sugar, frozen orange juice, canola, world cotton, US grains, precious metals, MSCI indices, all currency pairs, and US Dollar Index. This was previously tied to this ticket for ICE Futures Europe and ICE Endex. However, we've decided to release ICE Futures Europe and Endex first separately from ICE US.

Make our historical and live APIs easier to integrate from Java.

For the purpose of error recovery, it is very important to have a sequenced stream, where each message has a monotonically increasing field that can serve as a sequence number. For OPRA messages, the timestamps are only guaranteed to be increasing within each line. Currently, the line that a message came from can be inferred by (root, is_odd_strike, is_put, is_odd_day), but OPRA will be changing the way messages are distributed over lines, breaking this heuristic. After Q4 2026, the only way to find out which line a message came from would be to include the information in the message itself. Please see: "New OPRA Dynamic Rebalance Symbol Distribution – Go Live Timeframe: Q4, 2026" https://cdn.opraplan.com/documents/OPRA_Dynamic_Symbol_Load_Balancing_Plan_Effective_Q4_2026.pdf

The EQUS.MINI dataset does not have the status schema in either the Historical or Live API. This schema is needed for determining if symbols are trading (e.g. open for quoting/trading, or if they were halted or resumed mid-session). As a workaround, users may use the status schema from other US equities datasets such as XNAS.BASIC or IEXG.TOPS (Nasdaq Basic, IEX Tops) through the historical API. However, these are only available on a 15-minute delay without additional licensing fees.

We originally spec'ed the intraday replay to exactly 1 week, guaranteeing it's past an exchange maintenance window/scheduled weekend halt, so that majority of our customers could easily stitch historical and real-time data together unless the venue is truly 24/7 (most "24 hour" traditional venues still have a weekend halt). However the message rates have gotten so high this year that we can only guarantee replay up to 24 hours. This means that a customer that needs to stitch history from >24 hours ago to real-time data will need to do something tedious like the following: Subscribe to the real-time feed with start=0 and keep queuing up the real-time data.Use the first ts_recv timestamp plus some buffer (let's say ts_recv + 10min or ts_recv + 1 min) as the end parameter in an analogous timeseries.get_range request.Use either of these as the index to join your historical data with the queued real-time data: (A) channel_id and sequence_no as a pair - Most correct, but also most tedious. (B) ts_recv - Much easier but could be out of order within a factor of ~1 microsecond at the boundary between historical and queued real-time due to PTP sync error. (C) ts_event - Just as easy as using ts_recv, avoids the sync error at the boundary and works on most current venues which enforce FIFO and monotonic timestamps, however not guaranteed to be correct on all venues since not all venues truly respect monotonicity. Cut over to the real-time stream. Note: The above choice of A/B/C also depends on your business logic and the schema you're using. Most of our schemas are stateless so it might not matter if you have ~1 mic of error at the boundary. Most features/alpha signals are probably stable to that. Even if you're using a stateful schema like MBO, I imagine most downstream applications and business logic should be robust to that ~1 mic out-of-order MBO events at the boundary using ts_recv. The "queue" above may be some kind of message middleware that you can insert into that enforces a sort order on ts_recv—for example, not that this would be a recommended or efficient pattern, you could imagine a database serving as a hacky message middleware could enforce sort on the ts_recv column.

This feature would allow the user to request trading calendar information (such as trading session start/end times) via our API. This is especially useful when considering trading sessions that can span multiple UTC dates (and hence the possibility of having multiple trading sessions within a single day)

Data for Eurex, including all schemas (MBO, MBP, ohlcv, etc.).

Currently, equities is supported via individual prop feeds of each venue. While NASDAQ is sufficient for getting NBBO for most of the time, some users prefer something that will be more in line with actual NBBO from SIPs. This feature request tracks 3 possible modes of consolidation for both historical and live data: Databento server-side consolidation of multiple proprietary feeds Consolidated data from proprietary feed like Nasdaq Basic in lieu of SIP Consolidated data from CTA/UTP SIPs We plan on implementing 1-2 of these three options.

All orders plus last look quotes from 35 major banks and non-bank LPs, on one of the largest FX venues.

For options, including in the CME and OPRA datasets, the existing MBP-1 schema can have significant record volume despite the instruments being extremely illiquid. In practice, there are several orders of magnitude more MBP-1 records than trades, which is unwieldy to work with. We're introducing a new schema to resolve this. BBO on interval (bbo-1s, bbo-1m) will provide the last best bid, best offer, and sale at 1-second or 1-minute intervals. This is different from BBO on trade (tbbo), which is a subset of our MBP-1 schema and provides every trade event alongside the BBO immediately before the effect of each trade. The main distinction is that TBBO is captured in trade space, while BBO is captured in time space. Learn more in our MBP-1 vs. TBBO vs. BBO schemas guide. Update: The BBO schema will be supported for all symbols on all datasets, not only options. This description focuses on options as that's where the benefit would be maximized (since options have much larger order-to-trade ratios). We'll roll this out for CME first, followed by equities and ICE, and then OPRA.