Product roadmap

The legacy live usage-based plans allowed users to access L2/L3 data. However L2/L3 were pulled from the Standard plan. One possibility to increase the value of the Standard plan is to offer limited access to L2/L3, perhaps gated by a quota on symbol subscriptions per account, etc.

Currently, multi-leg products (spreads, strategies, combos) on CME/ICE are hard to use because our instrument definitions do not provide metadata about each underlying leg. The user has to infer the legs from the symbol. This is a form of lossy normalization, since CME/ICE does provide this in their security definitions in a repeating group, but our fixed instrument definition schemas are forced to discard this—they only provide the the instrument_id of the first underlying instrument through underlying_id. In the meantime, our recommendation to users is to either infer this from the symbol OR download the raw security/instrument definitions from the exchange (e.g. CME's is free on their FTP) OR get a pcap subscription from us. If you need historical secdefs copied from CME (since their FTP site only gives 1 day history), we can provide a courtesy backfill of these for a fixed cost.

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). Keywords: Market calendar, trading holidays.

To extend support to browser-based applications.

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.

Historical and live market news.

Only regular trading hours are supported currently.

Original request from Juan Linares: "Great product but please add dark mode." There are two separate parts to this: Dark mode for the portal and main website (databento.com, databento.com/portal) Dark mode for the docs We can consider this only after Q1 2025 since we're doing a major rebranding of our website which is expected to finish by early April 2025. The new colors will make it easier for us to implement a dark mode.

It would be helpful if OPRA trade conditions were included in the normalized schemas. This is useful information that's currently lost during normalization. Also include the "message type" of each last sale message. Similar to: https://roadmap.databento.com/roadmap/us-equity-trade-condition-codes

It would be great if Japan Exchange Group (Nikkei 225, etc) could be supported. CME Nikkei 225 volume is too low.

Kalshi is a regulated exchange where you can trade on the outcome of real world events: https://kalshi.com/

Currently, we only have BBO data on intervals. It would be great if we could also get interval based snapshots of deeper levels in the orderbook.

Over the next 3 months, Databento will be releasing an expansion of our US equities coverage, new flat-rate tiers across all datasets for our mid-market users (internally referred to as a "Pro" tier) , and reduced fees for some of our Enterprise tier plans. We'll also be making it possible for users to subscribe to live and historical Enterprise plans separately. We believe these changes will make data more accessible to our median spending user and provide most users with more ways to manage variable pricing uncertainty.

Hello Databento team, I wanted to suggest a small API feature that would be useful for developers who automate historical data downloads. It would be very helpful if the API could return my account’s current balance, such as credits remaining or the current amount owed so far for the billing period. The main reason is budget control. I may want to set a monthly cap for how many credits I use or how much money I spend on data. If my application could check the current balance through the API, it could automatically stop downloading data before exceeding that limit. This would be especially useful because historical data downloads can take time, and I like being able to let downloads continue while I am away from the computer without having to constantly monitor the portal. Since the API already has access to my account and Databento knows the current pricing and usage so far, this would make automated data downloads much safer without requiring constant manual monitoring. Thanks for considering it.