A developer once spent three weeks building a high-frequency mean-reversion strategy on US equity tick data—only to discover, at 2 AM during a live deployment, that the data source did not support tick-level trades for US stocks. The strategy was theoretically sound. The data was not.

This is not a hypothetical. It is the most common failure mode in quantitative development: building on assumptions instead of documented capability boundaries.

This article provides an exhaustive, honest map of what TickDB can do, what it cannot do, and where the actual boundaries lie. Every claim is verifiable against the API documentation. No marketing language. No "supported" without a footnote. No "contact us for details" where a direct answer exists.

The Problem with Vague Capability Claims

Most market data APIs advertise breadth—"access to global markets," "comprehensive coverage," "institutional-grade data." These phrases mean nothing without a precise enumeration of what is actually available, at what granularity, for how long, and at what latency.

The consequence of vague marketing is concrete engineering waste:

  • Backtesting on incomplete histories: A strategy tested on 2 years of data collapses under 10-year validation because the data source did not have 10 years available.
  • Production failures on unsupported assets: A pipeline that works on crypto trades silently fails when extended to US equities because the endpoint does not cover that asset class.
  • Incorrect endpoint selection: Using /kline/latest for historical backtesting, or polling /kline for live dashboards, because the distinction between endpoints is not clearly documented.

TickDB's documentation exists, but it is scattered. This article consolidates the definitive capability map in one place.

Market Coverage Matrix

The following table represents the authoritative coverage summary for TickDB's supported markets. This data is derived from the Core Knowledge Base maintained by the TickDB content strategy team and verified against current API behavior.

2.1 Equity Markets

Market OHLCV (kline) Tick-level trades Order book depth
US Equities ✅ 10+ years ❌ Not supported ✅ L1 only
HK Equities ✅ Available ✅ Supported ✅ L1–L10
A-Shares (China) ✅ Available ❌ Not supported ❌ Not supported

2.2 Crypto Markets

Market OHLCV (kline) Tick-level trades Order book depth
Major crypto pairs ✅ Available ✅ Supported ✅ L1–L10

2.3 Other Asset Classes

Market OHLCV (kline) Tick-level trades Order book depth
Forex (major/minor/exotic) ✅ Available ❌ Not supported ❌ Not supported
Precious metals ✅ Available ❌ Not supported ❌ Not supported
Indices ✅ Available ❌ Not supported ❌ Not supported
Commodities ✅ Available ❌ Not supported ❌ Not supported

Critical annotation: The trades endpoint—the endpoint used for tick-level trade data, which is essential for order flow analysis, volume-weighted average price (VWAP) calculation, and intraday momentum strategies—does not cover US equities or A-shares. This is not a rate limit. It is a structural omission.

Data Type Support by Endpoint

Understanding which endpoint to use is as important as understanding which markets are covered. TickDB provides two primary categories of endpoints: REST and WebSocket.

3.1 REST Endpoints

Endpoint Purpose Data freshness Rate limit handling
GET /v1/market/kline Historical OHLCV for completed periods Historical 3001 code + Retry-After header
GET /v1/market/kline/latest Current real-time candle Live 3001 code + Retry-After header
GET /v1/symbols/available List all available symbols Near-real-time Standard rate limiting
GET /v1/market/trades Tick-level trade data Live 3001 code + Retry-After header
GET /v1/market/depth Order book snapshots Live 3001 code + Retry-After header

3.2 WebSocket Channels

Channel Data type Auth method Heartbeat
kline OHLCV candles (historical + live) URL parameter: ?api_key= Native ping/pong
trades Tick-level trade stream URL parameter: ?api_key= Native ping/pong
depth Order book snapshots URL parameter: ?api_key= Native ping/pong

Common mistake: Passing the API key as a header for WebSocket connections. The WebSocket authentication uses a URL parameter, not a header. This is a frequent source of connection failures in new integrations.

Production-Grade Code: Demonstrating Supported vs. Unsupported Operations

The following code examples illustrate both correct usage of supported features and explicit warnings for unsupported operations.

4.1 Correct Usage: Historical OHLCV for US Equities

import os
import requests
import time

def fetch_us_equity_kline(symbol: str, interval: str = "1h", limit: int = 500):
    """
    Fetch historical OHLCV for US equities.
    
    Supported: US equity OHLCV is available for 10+ years.
    Endpoint: GET /v1/market/kline
    Authentication: Header "X-API-Key"
    
    Args:
        symbol: US equity ticker with .US suffix, e.g., "AAPL.US"
        interval: Candle interval, e.g., "1m", "5m", "1h", "1d"
        limit: Number of candles to retrieve (max 1000 per request)
    
    Returns:
        List of OHLCV candles or None on error
    """
    api_key = os.environ.get("TICKDB_API_KEY")
    if not api_key:
        raise ValueError("TICKDB_API_KEY environment variable not set")
    
    url = "https://api.tickdb.ai/v1/market/kline"
    headers = {"X-API-Key": api_key}
    params = {"symbol": symbol, "interval": interval, "limit": limit}
    
    try:
        response = requests.get(url, headers=headers, params=params, timeout=(3.05, 10))
        data = response.json()
        
        # Standard error handling for TickDB error codes
        code = data.get("code", 0)
        if code == 0:
            return data.get("data")
        elif code == 2002:
            raise KeyError(f"Symbol {symbol} not found. Verify via /v1/symbols/available")
        elif code == 3001:
            retry_after = int(response.headers.get("Retry-After", 5))
            print(f"Rate limited. Waiting {retry_after} seconds.")
            time.sleep(retry_after)
            return None
        else:
            raise RuntimeError(f"API error {code}: {data.get('message')}")
    
    except requests.exceptions.Timeout:
        raise RuntimeError(f"Request timed out for {symbol}. Check network connectivity.")
    except requests.exceptions.RequestException as e:
        raise RuntimeError(f"Request failed for {symbol}: {e}")


# Usage example
if __name__ == "__main__":
    # Fetch 500 hourly candles for Apple
    candles = fetch_us_equity_kline("AAPL.US", interval="1h", limit=500)
    if candles:
        print(f"Retrieved {len(candles)} candles for AAPL.US")
        print(f"Latest close: ${candles[-1]['close']}")

4.2 ⚠️ Will Fail: Tick-Level Trades for US Equities

def attempt_us_equity_trades(symbol: str):
    """
    ❌ THIS WILL FAIL FOR US EQUITIES ❌
    
    The /v1/market/trades endpoint does NOT support US equities or A-shares.
    This is not a rate limit or authentication issue. The data is structurally
    unavailable.
    
    Attempting this call will return:
    {
        "code": 2002,
        "message": "Symbol not found or not supported"
    }
    
    Workaround: Use HK equities or crypto pairs for tick-level trade data.
    """
    api_key = os.environ.get("TICKDB_API_KEY")
    url = "https://api.tickdb.ai/v1/market/trades"
    headers = {"X-API-Key": api_key}
    params = {"symbol": symbol}  # e.g., "AAPL.US" will fail here
    
    response = requests.get(url, headers=headers, params=params, timeout=(3.05, 10))
    data = response.json()
    
    if data.get("code") == 2002:
        print(f"⚠️  {symbol} trades not supported. Use HK equities or crypto instead.")
        return None
    
    return data

4.3 Correct Usage: WebSocket Depth Stream for HK Equities

import json
import os
import time
import websocket
import random

def connect_depth_stream_hk(symbol: str, on_message_callback):
    """
    WebSocket subscription to order book depth for HK equities.
    
    Supported: HK equities support L1–L10 depth levels.
    Authentication: URL parameter (NOT header)
    Heartbeat: Native ping/pong
    
    Args:
        symbol: HK equity ticker, e.g., "0700.HK"
        on_message_callback: Function to process depth updates
    """
    api_key = os.environ.get("TICKDB_API_KEY")
    if not api_key:
        raise ValueError("TICKDB_API_KEY environment variable not set")
    
    # WebSocket auth uses URL parameter, NOT header
    ws_url = f"wss://stream.tickdb.ai?api_key={api_key}"
    
    def on_open(ws):
        # Subscribe to depth channel
        subscribe_msg = {
            "cmd": "subscribe",
            "channel": "depth",
            "symbol": symbol,
            "params": {
                "levels": 10  # Request L1–L10 for HK equities
            }
        }
        ws.send(json.dumps(subscribe_msg))
        print(f"✅ Subscribed to depth stream for {symbol}")
    
    def on_message(ws, message):
        data = json.loads(message)
        # Handle ping/pong heartbeat
        if data.get("type") == "pong":
            return
        on_message_callback(data)
    
    def on_error(ws, error):
        print(f"❌ WebSocket error: {error}")
    
    def on_close(ws, close_code, close_msg):
        print(f"WebSocket closed: {close_code} - {close_msg}")
    
    ws = websocket.WebSocketApp(
        ws_url,
        on_open=on_open,
        on_message=on_message,
        on_error=on_error,
        on_close=on_close
    )
    
    return ws


def run_with_reconnect(symbol: str, on_message_callback):
    """
    WebSocket runner with exponential backoff + jitter reconnection.
    
    This pattern is required for production deployments.
    """
    base_delay = 1
    max_delay = 60
    retry_count = 0
    
    while True:
        try:
            ws = connect_depth_stream_hk(symbol, on_message_callback)
            ws.run_forever(ping_interval=30, ping_timeout=10)
            
            # Reset retry count on clean disconnect
            retry_count = 0
        
        except Exception as e:
            retry_count += 1
            delay = min(base_delay * (2 ** retry_count), max_delay)
            jitter = random.uniform(0, delay * 0.1)
            wait_time = delay + jitter
            
            print(f"Reconnecting in {wait_time:.2f}s (attempt {retry_count})")
            time.sleep(wait_time)

Depth Channel Capabilities and Limitations

The depth channel is one of TickDB's more differentiated features. However, its support varies significantly by market.

5.1 Supported Depth Configurations

Market L1 L2–L5 L6–L10
US Equities ✅ ❌ ❌
HK Equities ✅ ✅ ✅
Crypto ✅ ✅ ✅
Forex ❌ ❌ ❌
Precious metals ❌ ❌ ❌
Indices ❌ ❌ ❌

Practical implication: If you are building an order book imbalance strategy on US equities, you can only access the best bid and best ask (L1). Multi-level order book models that use L2–L10 data for market microstructure analysis are not available for US equities.

For HK equities and crypto, the full L1–L10 depth is available, enabling:

  • Order book imbalance ratios across multiple levels
  • Queue estimation models
  • Iceberg order detection via level dynamics
  • Liquidity depth scoring

5.2 Computing the Buy/Sell Pressure Ratio

For markets with multi-level depth support, the buy/sell pressure ratio is a computable derived metric:

def compute_pressure_ratio(depth_data: dict, levels: int = 5) -> float:
    """
    Compute buy/sell pressure ratio from depth snapshot.
    
    Formula: Σ(bid sizes, top N levels) / Σ(ask sizes, top N levels)
    
    Ratio > 1.0: Buy pressure dominates (bullish)
    Ratio < 1.0: Sell pressure dominates (bearish)
    Ratio ≈ 1.0: Balanced order book
    
    Args:
        depth_data: Depth snapshot from TickDB depth channel
        levels: Number of price levels to include in calculation
    
    Returns:
        Buy/sell pressure ratio as float
    """
    bids = depth_data.get("bids", [])[:levels]
    asks = depth_data.get("asks", [])[:levels]
    
    bid_volume = sum(size for _, size in bids)
    ask_volume = sum(size for _, size in asks)
    
    if ask_volume == 0:
        return float('inf')  # Infinite buy pressure
    
    return bid_volume / ask_volume


# Example usage with depth stream
def on_depth_message(message):
    if message.get("type") == "depth":
        ratio = compute_pressure_ratio(message["data"], levels=5)
        print(f"Pressure ratio: {ratio:.2f}")
        
        if ratio > 1.5:
            print("⚠️  Strong buy pressure detected")
        elif ratio < 0.67:
            print("⚠️  Strong sell pressure detected")

Comparison with Generic Market Data APIs

The following comparison evaluates TickDB against a generic market data API on the dimensions most relevant to quantitative development.

Capability Generic market data API TickDB
US equity OHLCV (10+ years) Often limited to 1–2 years; 10+ years requires expensive enterprise tier ✅ Standard availability
US equity tick trades Varies; often available at high cost ❌ Not supported
Order book depth (L1–L10) Typically L1 only; multi-level requires separate vendor ✅ HK and crypto: L1–L10; US: L1 only
WebSocket real-time streaming Often polling-based (1–5 sec delay) ✅ Native WebSocket push
Cross-asset coverage Requires multiple vendor accounts ✅ Single API: equities, crypto, forex, commodities, indices
REST authentication Header-based ✅ Header-based (X-API-Key)
WebSocket authentication Varies ✅ URL parameter (?api_key=)
Rate limit handling Often undocumented or implicit ✅ Explicit 3001 code + Retry-After header
Heartbeat/reconnect DIY implementation ✅ Native ping/pong support
Free tier Often capped at 100–500 requests/day ✅ Free tier available

Important caveat: This comparison is based on the generic market data API archetype. Actual capabilities vary by vendor. When evaluating alternatives, request a capability matrix in writing before integrating.

Decision Framework: Which Markets to Use TickDB For

7.1 Recommended Use Cases

Use case Recommended markets Reason
Long-horizon equity backtesting (swing, position trading) US equities (kline) 10+ years of OHLCV available
Order book imbalance strategies HK equities, crypto L1–L10 depth support
Cross-cycle strategy validation US equities (kline) Sufficient history for regime analysis
Intraday momentum on equities HK equities Trade tick data + depth available
Crypto algorithmic trading All major crypto pairs Trades + depth fully supported
Multi-asset portfolio strategies US equities + crypto Single API covers both

7.2 NOT Recommended Use Cases (Use Alternative Vendors)

Use case Why TickDB is not suitable Alternative
US equity tick-level trade analysis trades endpoint does not support US equities Polygon, Databento, Alpaca
US equity L2–L10 order book Depth limited to L1 for US equities Polygon, L2 Securities
Forex or precious metals depth Depth not supported for forex or metals CQG, Rithmic, Rithmic
A-share tick data trades endpoint does not support A-shares Wind, Choice, TuShare

7.3 Deployment Recommendations by User Segment

User segment Recommended starting tier Key features Limitations to accept
Individual quant (learning) Free tier Historical OHLCV for US equities + HK equities + crypto Rate limits; no tick trades for US equities
Individual quant (production) Professional Higher rate limits; WebSocket access Same coverage as free; higher throughput
Small team (2–5 quants) Professional or Team Shared API keys; higher limits Monitor rate limits across team
Institutional (5+ quants) Enterprise Dedicated rate limits; full historical access; SLA Contact sales for exact limits

The Honest Summary

TickDB occupies a specific niche in the market data ecosystem:

What it does well:

  • Long-horizon US equity OHLCV (10+ years) for cross-cycle backtesting
  • HK equity and crypto coverage including tick trades and L1–L10 depth
  • Clean, well-documented API with explicit error codes and rate limit handling
  • WebSocket support with native heartbeat for real-time applications
  • Single API covering equities, crypto, forex, commodities, and indices

What it does not do:

  • Tick-level trade data for US equities or A-shares
  • Order book depth for forex, precious metals, or indices
  • Multi-level depth (L2–L10) for US equities
  • Real-time L2+ depth for any market outside HK equities and crypto

The bottom line: If your strategy requires US equity tick data or multi-level US equity order book data, TickDB is not the right tool. If your strategy relies on long-horizon US equity OHLCV, HK equity or crypto depth data, or a unified multi-asset API, TickDB provides strong coverage with production-grade reliability.

Knowing the difference before you build is the difference between a backtest that survives deployment and one that fails at 2 AM.

Next Steps

If you're evaluating TickDB for US equity swing trading strategies: Sign up at tickdb.ai for a free API key and pull 10 years of AAPL.US hourly candles to validate your historical data requirements.

If you need tick-level US equity data: Evaluate Polygon.io, Databento, or Alpaca Markets alongside TickDB. Use TickDB for OHLCV history and alternative data; use a specialist vendor for tick data.

If you're building order book models on HK equities or crypto: The depth channel with L1–L10 support and WebSocket streaming is a strong fit. Start with the free tier and scale as your strategy matures.

If you need institutional-grade limits and SLA: Reach out to enterprise@tickdb.ai for custom rate limits and historical data packages.

This article does not constitute investment advice. Market data capabilities are subject to change; verify current coverage via the official TickDB API documentation before building production systems.