A crypto market data API looks simple when the first requirement is “show the price.” The difficulty appears when the product must explain which price, from which venue, at what time, with what liquidity, and whether the stream is complete. Centralized exchanges, decentralized exchanges, broker platforms, derivatives venues, and aggregators publish different market structures. A reliable data layer preserves those differences while giving charts and applications a consistent way to consume them.
This matters for more than trading terminals. A Digital Assets API app may use market data to value balances, create tax snapshots, trigger alerts, rank assets, or supply an AI assistant with context. An iOS or Android client needs compact responses and predictable caching. A high frequency trading system needs a different path with stricter latency and sequencing. One market-data architecture should not claim to satisfy every tier without explicit boundaries.
Define the market object precisely
A market is more than two ticker symbols. Store the venue, instrument type, base asset, quote asset, settlement asset, contract size, price increment, quantity increment, status, and trading session rules. Spot BTC-USD, a linear perpetual settled in USDC, and an inverse perpetual margined in BTC are different instruments even if their labels look similar.
Create a canonical market identifier and keep the venue product ID as an attribute. Normalize symbols for display only. Venue naming can change, and the same ticker can refer to different contracts on different networks. For decentralized exchanges, the pool address, fee tier, token contracts, and chain are part of identity.
Instrument metadata should be versioned. A price tick, minimum order size, or status change can invalidate order validation and chart assumptions. Capture effective time so historical events can be interpreted using the rules that existed when they occurred.
Use snapshots and streams together
REST endpoints are well suited to reference data, historical candles, and recovery snapshots. WebSockets are generally suited to continuously changing trades, quotes, order books, and account events. Production clients need both. The stream supplies low-latency updates; the snapshot creates a known starting point and repairs gaps.
The Coinbase Advanced Trade WebSocket documentation illustrates a common pattern: clients subscribe to named channels and receive JSON messages for selected products. The general lesson is not to hard-code one venue’s message types throughout the product. Translate them at the ingestion edge into a canonical event envelope.
A useful envelope includes event type, canonical market ID, source venue, source timestamp, ingestion timestamp, sequence or update ID, schema version, and raw-payload reference. Then place the venue-specific fields in an adapter. This lets downstream consumers process one event family while preserving enough evidence to debug a source discrepancy.
Treat order books as state machines
An order book is not a list that can be overwritten whenever a message arrives. It is state reconstructed from a snapshot plus ordered updates. The consumer must know whether updates replace a level, add a delta, or describe a full side. It must also know how sequence numbers relate to the snapshot.
The safe flow is:
- Open the stream and buffer updates.
- Request a current snapshot.
- Apply buffered updates that occur after the snapshot sequence.
- Reject duplicates and detect gaps.
- Rebuild from a new snapshot when continuity cannot be proved.
Keep bid and ask levels in price-sorted structures and remove zero-size levels according to the venue’s rules. Publish a book only when it is synchronized. A dashboard should expose last sequence, gap count, snapshot age, and update lag.
Aggregated books require additional choices. Prices may need to be rounded to a common tick, currencies converted, fees adjusted, and venue latency considered. Do not present an aggregated book as directly executable unless the product also models venue balances, transfer constraints, order rules, and routing latency.
Build a canonical trade and quote model
A trade event should identify price, quantity, side convention, trade ID, event time, and whether the venue marks the aggressor. Side semantics vary; “buy” may refer to the maker, taker, or user order. Name the field explicitly, such as taker_side, rather than assuming a universal side.
Quotes can mean best bid and ask, a last trade, a midpoint, an index, or a calculated fair value. Use separate fields and labels. A portfolio valuation service may choose a midpoint for liquid markets and a guarded last price for others, but that policy belongs above the raw feed.
For decentralized exchange swaps, preserve transaction hash, log index, pool, token amounts, block context, and fee tier. A swap-derived price can be distorted by token taxes, unusual decimals, shallow pools, sandwich activity, or stale reserves. Quality filters should consider liquidity and route context rather than treating every onchain trade as equal.
Generate candles deterministically
Candles are derived data. Define the source events, interval boundaries, timezone, late-event policy, and whether zero-volume periods are emitted. Use event time, not ingestion time, unless the product explicitly wants a received-time chart. Store open, high, low, close, volume, trade count, and finality state.
The current interval remains mutable. Publish it as provisional, then mark it closed after the interval and any allowed late-arrival window. If historical corrections are possible, version the candle or publish a correction event. A chart that silently changes old bars without a trace is difficult to audit.
When combining venues, decide whether the candle represents a selected primary venue, a volume-weighted composite, or a calculated index. Label the methodology in metadata. Different methodologies are useful for different tasks, and none should be presented as “the market price” without explanation.
Adapt data for charting libraries
Charting systems typically require symbol resolution, supported intervals, historical bars, real-time subscriptions, timezone and session information, and price-format rules. Build a chart adapter over the canonical data service rather than connecting the browser directly to every venue.
For a TradingView-style integration, the backend should translate canonical markets into the datafeed’s symbol metadata and return complete OHLCV bars in the required time units. Keep API keys server-side. Route real-time events to subscriptions by canonical market and resolution, and ensure updates never move a bar backward in time.
Mobile apps benefit from a similar gateway. Send compact data, paginate older bars, compress responses, and pause subscriptions when the app is backgrounded. Reconnect with a cursor or snapshot rather than assuming the stream continued while the device was offline.
Score data quality, not only availability
Create quality signals for each feed: age, sequence continuity, message rate, crossed-book frequency, zero or negative values, deviation from peer venues, duplicate rate, and historical completeness. These signals can select a fallback source or warn the client that a value is degraded.
A composite price should have an inclusion policy. Exclude halted markets, stale venues, thin liquidity, and obvious outliers. Record which venues contributed and their weights. Keep the raw inputs so a valuation or alert can be reproduced later.
Provider and venue rate limits must shape the architecture. Centralize subscription management so multiple application clients do not open redundant upstream streams. Fan out normalized events internally. Apply backpressure by dropping replaceable interim quotes before dropping trades or state transitions that cannot be reconstructed.
Test with replay and deliberate faults
Capture representative raw sessions and replay them through the adapter. Include reconnects, duplicate sequence numbers, missing updates, symbol changes, partial snapshots, malformed messages, and late trades. A deterministic replay test is more valuable than a live smoke test because it can be repeated after every parser change.
Simulate a provider outage and confirm the product distinguishes “no trades” from “data unavailable.” Verify that charts stop or show stale status instead of drawing flat, fabricated prices. Test that a fallback does not mix incompatible instrument types or currency conventions.
The trading and derivatives API guide covers orders, positions, funding, margin, and perps. The blockchain API guide explains how onchain swaps and events enter the same data platform without losing block context.
Conclusion
A trustworthy crypto market data API is an ordered, observable state system. It combines snapshots with streams, canonical identity with source evidence, deterministic candle construction with clear methodology, and data-quality scoring with honest degradation. Once those foundations exist, CEX, DEX, broker, charting, web, and mobile consumers can share one platform without pretending their requirements are identical.
