data_start / data_end

Symbol metadata timestamps that indicate the overall start and end of available data for a symbol (outer bounds), often used as coverage windows.
back to all terms

data_start and data_end are symbol metadata timestamps that indicate the earliest and latest time for which data is available for a symbol in a dataset. They represent outer bounds of coverage (a coverage window) rather than a guarantee of continuous data. Many workflows use these fields to avoid querying outside the available range and to understand how far back a symbol’s history goes.

If you request historical data outside a symbol’s covered range, you may get empty responses or partial results that are easy to misinterpret. Using data_start / data_end helps you (1) bound queries, (2) build consistent universes with minimum history requirements, and (3) separate “no data because it didn’t trade” from “no data because it isn’t covered.”

Common uses include:

  • Excluding symbols whose data_start is after your backtest start.
  • Restricting API queries to max(request_start, data_start) and min(request_end, data_end).
  • Reporting coverage statistics across venues and instrument types. For more robust pipelines, you track additional, data-type-specific coverage fields (trades vs quotes vs order books).

Some datasets expose an overall data_start/data_end plus more specific fields such as data_trade_start/data_trade_end and data_quote_start/data_quote_end. The specific fields are more reliable when your analysis depends on that data type. For example, spreads require quotes coverage, not just overall coverage.

Not necessarily. They describe the dataset’s coverage, which may start after a true listing and may end before a true delisting due to collection, normalization, or integration changes. Use them as coverage bounds, not authoritative lifecycle dates.

For symbols that are still active, data_end may be near “now” and may update over time. Treat it as a moving boundary that reflects the most recent covered timestamp, not a fixed property. For reproducibility, store the metadata snapshot timestamp you used.

Use the data-type-specific fields whenever possible because they match the exact inputs your strategy or metric needs. Use data_start/data_end as a coarse first filter or when only overall coverage is available. Mixing them without tracking the difference can lead to missing features and biased results.

You backtest a strategy from 2020–2024 and include a symbol that was listed in 2023. Its data_start is in 2023, so it should not be included in the universe in 2020–2022. If you mistakenly include it anyway and treat missing early data as zeros, you introduce lookahead and survivorship-like distortions.

Crypto API made simple: Try now or speak to our sales team

Start for FreeGet in Touch
CoinAPI.io Glossary - data_start / data_end