symbol_type

A symbol metadata field that classifies an instrument (e.g., SPOT, FUTURES, PERPETUAL, OPTIONS), used for filtering and correct analysis.

symbol_type is a symbol metadata field that classifies what kind of instrument a symbol represents, such as spot, futures, perpetual swaps, or options. It is used to filter symbol lists and to ensure analytics and strategies apply the correct assumptions for the instrument category. The exact set of values depends on the dataset/provider, but the intent is consistent: distinguish instrument types.

Instrument type impacts pricing behavior, lifecycle, and required fields. For example, futures have expiry, perpetuals have funding, and options have strike and greeks. If you ignore symbol_type, you may mix fundamentally different instruments in the same universe and produce misleading results. It also helps prevent phantom symbols and duplicates when multiple instrument types share similar base/quote assets.

Typical steps are:

  1. Pull symbol metadata.
  2. Filter by symbol_type (for example, SPOT).
  3. Apply additional constraints (venue, quote currency, tradability).
  4. Enforce coverage windows for the data type you will query. This is often done point-in-time for backtests so the instrument classification is time-consistent.

A common mistake is inferring instrument type from the symbol string rather than metadata, which breaks on venue-specific naming schemes. Another is applying today’s symbol_type values to historical periods if a symbol identifier was reused or renamed. Finally, failing to filter can lead to comparing spot metrics with derivatives metrics.

Common values include SPOT, FUTURES, PERPETUAL, and OPTIONS. Some venues also distinguish between dated futures and other contract types. Always rely on the metadata value rather than hardcoding assumptions from symbol text.

No. symbol_type tells you what the instrument is, not whether it is liquid, accessible, or actively trading. To define tradability, add filters based on spreads, depth, and recent trades/quotes, evaluated point-in-time.

A PIT universe requires that every rule be evaluated as of time t. symbol_type helps define the rule set (“only SPOT”) but you must still ensure the classification and membership are applied time-consistently and bounded by coverage windows.

You want to compute OHLCV returns for spot markets only. If you include derivatives symbols, roll/expiry effects and funding-like dynamics can contaminate the return distribution. Filtering your symbol list to symbol_type = SPOT avoids mixing different instrument behaviors.

CoinAPI exposes symbol_type in its symbol metadata so you can construct clean universes (spot-only, perpetual-only, etc.). Combine symbol_type filtering with coverage windows (data_start/data_end and type-specific fields) to request only the data that exists for the instruments you intend to analyze.

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