Product roadmap

This serves as a master list of all other snapshot-like features on our roadmap. The scope of this ticket is potentially very large and ambiguous so we've broken this down into smaller tickets that you can follow separately. (Historical only) https://roadmap.databento.com/b/n0o5prm6/feature-ideas/add-historical-endpoint-for-latest-snapshot-of-any-schema. This would allow a user to get the latest published value of any given schema, within the boundaries allowed by licensing/entitlements/historical embargo window. The main benefit of this is for creating ticker tape or latest quote features, e.g. on a web app, after we start exposing intraday data over the historical/HTTP API (https://roadmap.databento.com/roadmap/expose-intraday-and-current-trading-session-historical-data-over-historical-http-api-and-clients). Likely endpoint names for this would be either timeseries.get_last or timeseries.get_snapshot. (Historical only) https://roadmap.databento.com/b/n0o5prm6/feature-ideas/provide-snapshots-as-of-specified-time-in-historical-api. Likely endpoint names for this would be either timeseries.get_last or timeseries.get_snapshot.(Live only) https://roadmap.databento.com/roadmap/add-periodic-mbo-book-snapshots-to-live-api. This allows a user to get the last published value of any given schema at a specified time. The main benefit of this would be to allow customers to subsample the data on server side and reduce cost, though the benefit is diminished with feature 5 on this list. Note that this would allow a user to emulate (1) relatively well since a user could potentially just pass in their current clock time or some time slightly ahead of the clock time. However, their underlying implementations would be different and (1) and (2) would likely be released separately. Likely endpoint names for this would be either timeseries.get_last_asof or `timeseries. (Live only) https://roadmap.databento.com/b/n0o5prm6/feature-ideas/allow-live-api-clients-to-request-for-mbo-snapshot-recovery. This provides resilience to gaps or data errors originating from Databento side. It could also be used for recovery of book state caused by client-side issues or disconnection, but would be less quick than feature (4) on this list.(Both historical and live) https://roadmap.databento.com/roadmap/fixed-interval-mbp-1-summaries-eg-1-minute-bbo-or-subsampled-bbo. The purpose of this is more to provide customers a convenience over fetching or subscribing MBP-1 and subsampling and forward filling the MBP-1 data themselves, which could be very expensive given the size of MBP-1 data and how the customer has no idea how far to look back for the "last" MBP-1 update prior to the 1 second or 1 minute refresh interval. Some of these are in development, hence the status of this entire ticket, however you should check on each individual one in case the specific feature you're looking for is still in Considering state.

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.

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.).

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

This ticket tracks the feature of releasing historical data as early as permissible. Currently, we embargo historical data strictly at a 24h cutoff to ensure that it is distributed safely as historical data for every venue, thus sidestepping real-time/delayed licensing requirements for our users. However, many venues actually define their "historical" boundary as the same date in venue local timezone OR the session end. So in theory, if a session ends at 8 PM ET, it would be possible to distribute data from the same day at 7.59 PM ET at 8 PM ET. Currently, to get data from within the trading session, you must use the live API (through Raw API or a live client of the Raw API). However, the Raw API can be unwieldy for a range of use cases that require a small amount of data from the current trading session. For example, if the user only needs a few instrument definitions, settlement prices, or wants to update a ticker tape based on subsampled OHLCVs, it is usually preferred to use a request-response model like our HTTP API; setting up and tearing down a stateful TCP subscription for the live API is probably too hefty for this feature. Once released, users should be able to access intraday historical data via HTTP API so long as they have a live data entitlement. See also: https://roadmap.databento.com/b/n0o5prm6/feature-ideas/provide-snapshots-for-historical-and-live-data

It might be possible to obtain CME trading session hours systematically in historical captures of the instrument definition messages, as embedded in tag-1682=MDSecurityTradingStatus. This ties to another proposed feature here.

A schema to encompass useful EOD information in various forms. Currently, users have to extract EOD prices from ohlcv-1d. However, this is aligned to UTC midnight. Users who want EOD data based on session end or other specific conventions, e.g. 3:45 PM ET (to avoid auction) have to extract this from ohlcv-1h or ohlcv-1m data. This could be provided either in the form of a new endpoint, new schema (e.g. 'ohlcv-eod' or 'eod'), or more session/market calendar functionality.

This would allow a user to get the latest published value of any given schema, within the boundaries allowed by licensing/entitlements/historical embargo window. Likely endpoint names for this would be either timeseries.get_last or timeseries.get_snapshot. The main benefit of this would be to support ticker tape-type use cases, especially when we've enabled entitlements to intraday data through the HTTP API. See also: List of other snapshot features on the roadmap

Currently, our API uses UTC time for all trading venues. So for example, the open price of ohlcv-1d for a given date, say start='2022-09-12', will be 2022-09-12T00:00+0 for two different venues in two different timezones (e.g. NASDAQ, LSE). There are advantages to this approach: This is useful for synchronizing time series across multiple venues, e.g. for a global equities portfolio. It's easier for programmatic timezone conversions. The time parameters are always in 1 timezone and consistently unaffected by daylight savings; it's generally easier to map from UTC to any preferred timezone. Downsides: This is inconvenient for users who are only trading 1 venue. This is inconvenient for users who just want to do a quick manual lookup; have an exploratory Excel workflow; or have a charting use case. For example, most people know off the top of their head that 09:30 ET is the start of regular trading hours on NASDAQ, but they might not know what that time is in UTC. It is tricky to map from opening/closing prices in UTC 00:00 day to opening/closing auction price. On some venues, opening/closing auctions may be extended and don't always align with a fixed time. Moreover, most trading venues don't use midnight as the start of the trading session and have trading sessions spanning two days. For example, CME's trading session for Monday actually starts on Sunday in Chicago time. A potential solution to this is to extend our API and portal functionality, while keeping the current UTC-based time as default behavior: Add advanced customization that lets users specify time in "market time zone". Add advanced customization that lets users specify dates in "trading session date". Extend API methods to accept start/end time in "market time zone", without the user having to do lower-level timezone conversions themselves. e.g. A flag like tz='local'. Extend API methods to accept start/end time in "trading session date".

Currently, we only support the standard Python versions and not the free-threaded interpreters. Supporting this will require some work in databento-dbn and perhaps dependencies of the databento package.

Hi, Would it be possible to add VWAP aggregation using trade tick data (price & size) to OHLCV bar schema? This would save a lot of effort to subscribe to high frequency tick data and do this aggregation locally. Also this would be more accurate compared to the HLC/3 VWAP calculation using already aggregated bar data.

Currently, OHLCV records for OPRA are provided on a per-venue basis. This ticket will allow users to get a single consolidated response across all US Equities Options venues across each specified time interval. In the interim, users must ingest trade data and create their own OHLCV records from the consolidated trade data.

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.