CuteMarkets Docs

API Reference

Everything you need to integrate market data, build faster, and scale.

Tip: open /docs/quotes-trades-aggregates-semantics.md directly for raw markdown (easy copy/paste into an LLM).

Market-data bugs often start with one vague word: price. A quote, trade, aggregate close, midpoint, snapshot value, and model mark can all be called a price inside an app, but they answer different questions.

Use this guide to label market-data fields clearly in dashboards, scanners, research notebooks, alerts, and backtests.

Quick answer

Quotes show advertised bid and ask markets. Trades show executed prints. Aggregates summarize qualifying trades into bars. Snapshots combine latest state fields for convenience. A reliable application labels which object produced each value and avoids using one object as a silent substitute for another.

The core objects

ObjectAnswersGood forRisk if misused
QuoteWhat bid and ask were shown at a timestamp?Spread checks, executable context, quote-aware fills, scanner liquidity filters.Can change quickly and can be wide, crossed, locked, stale, or missing.
TradeWhat actually printed?Tape review, volume, last-sale state, event study, aggregate construction.Last trade can be stale and may not be executable now.
AggregateWhat did qualifying trades do over an interval?Charts, indicators, compact backfills, daily reports.Bar highs and lows are not guaranteed fill prices.
SnapshotWhat is the latest convenient state bundle?Detail pages, watchlists, current chain views.Snapshot fields may mix quote, trade, reference, and derived values.
ReferenceWhat instrument is this?Symbol validation, contract identity, ticker search.Reference is not market state.

Quotes are not trades

A trade is evidence that two parties executed at a price. A quote is evidence that a market was advertised at a bid and ask. Both can be correct while appearing to disagree. In options, the last trade can be minutes or hours old, while the quote has moved with the underlying.

If a UI uses last trade as a display value, label it as last trade. If a strategy uses bid/ask context for entries, store the quote row, quote timestamp, bid, ask, midpoint, spread, and any reject reason. Do not rewrite those as a generic price without metadata.

Aggregates are context, not fill proof

Aggregates are useful because they compress many trade rows into open, high, low, close, volume, VWAP, and trade count fields. They are not proof that an order could have filled at the bar high or low. For backtests, use completed bars to create signals and quote evidence to model fills after the signal timestamp.

Sparse options contracts make this especially important. A one-minute bar with one qualifying trade is different from a one-minute bar with hundreds of trades. Store the trade count and volume alongside the OHLC values.

Snapshot values need source context

Snapshots are convenient because a single response can include latest quote, latest trade, Greeks, implied volatility, underlying context, and reference fields. That convenience is also the trap. When a downstream job consumes a snapshot, it needs to know which nested field it used and what timestamp belongs to that field.

For example, an options scanner might rank by implied volatility, filter by open interest, reject contracts with wide quotes, and display last trade. Those are four different concepts. The saved scanner result needs to preserve each source field separately.

Naming pattern

Prefer explicit names in storage and UI:

Generic name to avoidBetter names
pricelast_trade_price, bid_price, ask_price, midpoint_price, bar_close, mark_price
timequote_timestamp, trade_timestamp, bar_start, request_timestamp
volumetrade_size, bar_volume, session_volume, open_interest
tickerunderlying_ticker, option_ticker, contract_ticker

Common implementation checks

  • Store quote and trade rows in separate tables or with explicit object type.
  • Preserve row-level timestamps, not only request timestamps.
  • Keep request_id with the job or artifact that used the data.
  • Record whether the data was live, delayed, or historical.
  • For backtests, store why a fill was accepted or rejected.
  • For charts, document whether missing intervals mean no qualifying trades or a fetch gap.

Related CuteMarkets docs

Next steps

Move from the docs into the product workflow

If you are evaluating the API rather than implementing a specific endpoint right now, the product pages map live and historical workflows for stocks, options, and WebSockets.