Blog

Is CoinAPI historical data truly tick-by-tick or aggregated?

CoinAPI provides both tick-by-tick and aggregated crypto market data, giving traders and developers full control over how they reconstruct markets, analyze liquidity, and build trading systems. This guide explains the differences between tick data, OHLCV data, reference rates, and snapshot.

Is CoinAPI historical data truly tick-by-tick or aggregated?

Short answer

Both. CoinAPI delivers tick-by-tick data for trades, quotes, and full order-book updates, and provides aggregated datasets such as OHLCV bars, normalized order-book snapshots, exchange-rate series, and indexes. The exact format depends on the product and endpoint you use.

  • Trades:
    • Real-time: tick-by-tick via WebSocket/FIX
    • Historical: deduped and reconciled T+1 canonical files
  • Order books (full depth):
    • Real-time: tick-level incremental updates (ADD/SUB/MATCH/DELETE/SNAPSHOT)
    • Historical: full-depth T+1 via Flat Files (T_LIMITBOOK_FULL)
  • Quotes (best bid/ask – L1):
    • tick-level in real time and T+1 historical files
  • Order-book REST snapshots:
    • L2 depth, top 20 bids + 20 asks
    • downsampled cadence (not tick-level)
  • OHLCV data:
    • aggregated 1m, 5m, 1h, 1d bars (built from tick streams)
  • Exchange Rates API
    • VWAP-based aggregated reference rates (real-time + historical)
  • Indexes API
    • Benchmark/thematic/multi-asset index time series

T+1 historical datasets are the canonical version: corrected for late events, deduped, venue-adjusted.

Small differences from real-time streams are expected.

→ For a deeper explanation of why T+1 files differ from real-time streams, see our article:

Canonical Data in Crypto: Real-Time vs T+1

Most data providers only offer one side: either aggregated data (bars) or limited-depth snapshots. That creates problems:

  • You cannot replay execution paths accurately.
  • OHLCV data derived from partial ticks becomes biased.
  • You cannot reconstruct bid/ask spread or slippage.
  • You cannot train ML models on true microstructure.
  • Cross-exchange arbitrage opportunities become invisible.

By offering both tick-level and aggregated data, CoinAPI lets you choose the exact granularity required for your trading system.

Summary: Use tick data when accuracy matters; use aggregated endpoints when speed and simplicity matter.

Tick-level means:

  • One event = one row
  • No batching, sampling, or merging
  • Exact timestamps (exchange + CoinAPI)
  • Full chronological order preserved

High-volume markets like BTC/USDT regularly generate:

  • 1M+ trades/day, and
  • 5–20M order-book updates/day on a single exchange.

CoinAPI handles this scale with:

  • gzip-compressed CSV Flat Files (daily T+1)
  • unified schemas across all exchanges
  • aligned timestamps
  • real-time WebSocket/FIX streams using the same schema

Summary:

Tick-level = every trade, quote, and order-book event stored individually and in sequence.

→ To understand why this flat-file distribution model is crucial for quants and ML teams, see:

Crypto Data Download: The Flat Files Advantage.

CoinAPI uses a unified, timestamp-aligned schema across venues.

Each trade row includes:

  • symbol_id
  • time_exchange (UTC)
  • time_coinapi (UTC)
  • uuid
  • price
  • size (base units)
  • taker_side (BUY/SELL)
  • sequence (when provided)

Example

1{
2  "type": "trade",
3  "symbol_id": "BINANCE_SPOT_BTC_USDT",
4  "time_exchange": "2025-01-01T12:34:56.789Z",
5  "time_coinapi": "2025-01-01T12:34:56.790Z",
6  "price": 98765.43,
7  "size": 0.0123,
8  "taker_side": "BUY",
9  "sequence": 123456789
10}

Each quote update includes:

  • symbol_id
  • time_exchange, time_coinapi
  • bid_price, bid_size
  • ask_price, ask_size
  • sequence (when available)

Example

1{
2  "type": "quote",
3  "symbol_id": "BINANCE_SPOT_BTC_USDT",
4  "bid_price": 98765.40,
5  "bid_size": 0.5,
6  "ask_price": 98765.50,
7  "ask_size": 0.48,
8  "sequence": 123456790
9}

Each order-book update includes:

  • symbol_id
  • time_exchange, time_coinapi
  • sequence
  • bids: array of { price, size, number_of_orders }
  • asks: array of { price, size, number_of_orders }

A level with size = 0 indicates a delete.

Example

1{
2  "type": "book",
3  "symbol_id": "BINANCE_SPOT_BTC_USDT",
4  "sequence": 123456800,
5  "bids": [
6    { "price": 98765.40, "size": 0.50, "number_of_orders": 3 }
7  ],
8  "asks": [
9    { "price": 98765.50, "size": 0.48, "number_of_orders": 2 }
10  ]
11}
12

Notes

  • Some fields vary by venue (sequence, number_of_orders).
  • REST historical order books are depth-limited (20/side) and downsampled.
  • Full-depth tick history is available through Flat Files.
  • Real-time WebSocket provides tick-level increments ideal for execution algos and microstructure research.
FeatureTick dataOHLCV dataMid/reference rate
ResolutionPer eventPer time windowPer timestamp
Includes order book?Yes (L2/L3)NoNo
Generated fromRaw exchange ticksCoinAPI tick streamsMultiple exchanges (VWAP)
Best forBacktesting, microstructure, ML, executionCharting, strategies, dashboardsValuation, pricing, risk models

Because CoinAPI builds OHLCV from full tick streams rather than exchange-provided aggregates, it avoids bias.

→ Deep dive here: OHLCV Data Explained.

→ To understand why different providers sometimes show different historical volumes, read:

Historical Crypto Data Guide: Why Volume Numbers Look Different.

Without tick-level data:

  • slippage analysis is unreliable
  • bid/ask reconstruction is impossible
  • ML models cannot detect microstructure patterns
  • arbitrage opportunities cannot be validated
  • backtests diverge sharply from real execution conditions

CoinAPI solves this by storing every individual event, with aligned timestamps and normalized schemas across exchanges. Traders and ML teams can:

  • rebuild any historical order book
  • generate their own OHLCV data
  • measure true spreads and liquidity
  • perform microstructure-level backtests
  • evaluate execution quality and fill simulation

Tick-level does not mean:

  • there is an event every microsecond
  • downtime gaps are filled synthetically
  • OHLCV data is stored as ticks
  • midpoints are stored as ticks

If no trading or order-book change occurred, no tick exists. Gaps reflect reality.

Yes. CoinAPI’s Exchange Rates API provides robust, VWAP-based reference prices across vetted exchanges.

  • Exchange variability: raw prices differ by venue; VWAP aggregation stabilizes them
  • Valuation: funds need a consistent “official” price for NAV reports
  • Pricing engines: internal systems require a single reference input
  • Cross-exchange strategies: avoids misalignment from venue-specific quirks
  • Real-time reference prices updated continuously
  • T+1 final prices reconciled across venues
  • REST, WebSocket, and JSON-RPC
  • Global coverage across hundreds of crypto pairs
  • Eliminates noise and outlier trades

Tick data tells you what happened.

Reference rates give you one clean price to act on.

→ Learn more in the dedicated deep dive: Crypto Exchange Rates API: Real-Time & Historical Pricing from One Source.

Yes. CoinAPI’s Indexes API provides transparent index time series:

  • Benchmarking: measure strategy performance against unbiased baselines
  • Risk modeling: use index series in factor or regime models
  • Thematic baskets: track segments like DeFi, layer-1s, AI tokens
  • Portfolio analytics: produce normalized charting and exposure metrics
  • Rules-based methodologies
  • Transparent constituent logic
  • T+1 finalized values
  • Multi-asset and single-asset variations
  • REST API + historical downloads

Tick-level → microstructure

OHLCV → time-series indicators

Exchange rates → valuation

Indexes → benchmarking & analytics

→ Read the full overview: Crypto Indexes – Everything You Need to Know.

Yes. CoinAPI stores multi-year tick-level data for trades, quotes, and full order-book updates (as supported by each exchange).

Historical tick data is delivered as:

  • gzip-compressed CSV
  • daily T+1 files
  • S3-compatible folder structure

Datasets include:

  • T_TRADES
  • T_QUOTES
  • T_LIMITBOOK_FULL (full-depth order book)

Each dataset is partitioned by date, exchange, and symbol, enabling parallel downloads and large-scale ingestion.

Each update includes an update_type representing one of:

  • ADD – new order added
  • SUB – volume reduced
  • MATCH – reduction caused by a trade execution
  • SET – overwrite an existing level’s size
  • DELETE – remove an order or aggregated level
  • SNAPSHOT – full book state

For L2, updates apply at the price-level; for L3, at the order-level (when available). Applying updates sequentially rebuilds the exact book at any timestamp.

Cancelled or expired orders appear as DELETE events.

Yes.

WebSocket and FIX real-time messages use the same field structure as the historical T+1 files.

This ensures:

  • no schema drift
  • consistent timestamp handling
  • the same format for training (T+1) and execution (real-time)

If you need both high-fidelity tick data and clean aggregated analytics datasets under one unified API stack, explore:

Want help choosing the right product mix?

Tell us your use case - execution, ML training, valuation, or analytics - and we’ll point you to the exact endpoints and data types to use.

Recent Articles

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

CoinAPI.io Blog - Is CoinAPI historical data truly tick-by-tick or aggregated?