API Reference

Quote and trade condition data is the context layer that keeps an options API from turning every print and every bid/ask update into the same kind of "price." Conditions, exchange identifiers, sequence numbers, corrections, and timestamps explain why a row exists, how it arrived, and whether a workflow can use it for display, aggregation, alerts, or backtests.

Use this page with Quotes, Trades, Quotes, Trades, and Aggregates, Data Sources and OPRA, Market Data Corrections and Missing Data, and Options Data Provider Evaluation.

Quick answer

An options quote row describes a bid/ask market. An options trade row describes an executed print. Condition codes, exchange ids, correction flags, sequence numbers, and timestamps tell the application how to interpret that market-data row. A serious scanner, dashboard, or backtest stores those fields instead of reducing the row to one price.

Terms used on this page

Why condition context matters

An options contract can show a latest trade, a current bid, a current ask, a midpoint, an aggregate bar, a chain snapshot, implied volatility, Greeks, and open interest. Those fields are not interchangeable.

When a workflow ignores condition context, it can accidentally:

• fill a backtest from a stale last trade instead of the available bid or ask
• include a corrected or ineligible print in an aggregate
• rank an alert from wide-spread volume without quote context
• display a delayed quote as if it were live
• compare a trade timestamp and quote timestamp from different event layers
• collapse exchange-specific context into a generic "price" label
• hide no-bid, empty-window, and missing-quote rejects

That is why Options Backtesting Execution Realism, Options Flow False Positives, and Unusual Options Activity Scanner Model all keep quote freshness, spread, trade context, and reject labels visible.

Quote rows versus trade rows

Fields to preserve in artifacts

When an application stores a historical replay artifact, a scanner alert, a support ticket, or a paper-trading audit row, preserve the fields that explain the decision.

Condition policy for backtests

A realistic options backtest needs a written policy before it runs. The policy does not need to be complicated, but it needs to be explicit.

This policy belongs beside Options Contract Selection, Backtesting Engine Loop, Backtesting Data Model, and Backtesting Robustness.

Condition policy for scanners

Scanners often overclaim because they turn one row into a conclusion. A better scanner uses condition and quote context as labels.

Use those labels with Unusual Options Activity, Options Chain API, Options Liquidity Scanner, Put/Call Ratio API, and Options Flow False Positives.

Provider evaluation questions

When comparing CuteMarkets with a broader data vendor, ask these questions before choosing a provider:

1. Are trade condition codes exposed, normalized, mapped, or hidden?
2. Are quote condition fields available for the workflow that needs them?
3. Are exchange ids returned on bid, ask, and trade rows?
4. Are correction indicators available on trades?
5. Are timestamp fields precise enough for the intended strategy?
6. Does the API expose sequence numbers for event ordering?
7. Are latest endpoints clearly separated from historical windows?
8. Can the provider explain which prints contribute to aggregate bars?
9. Does pagination preserve complete heavy quote and trade windows?
10. Are live, delayed, and quote entitlements visible in responses or logs?

Pair this checklist with Market Data API Due Diligence Checklist, Options Data Vendor Checklist, Best Options Data APIs, and Compare Options Data APIs.

Example replay note

For a replay of an earnings move, store a note like this with the selected contract:

{
  "underlying": "NVDA",
  "options_ticker": "O:NVDA260619C00120000",
  "decision_time_utc": "2026-05-28T19:55:00Z",
  "quote_policy": "long_entry_ask_exit_bid",
  "quote_window_ms": 30000,
  "trade_window_ms": 60000,
  "max_spread_percent": 12,
  "required_fields": [
    "bid_price",
    "ask_price",
    "sip_timestamp",
    "bid_exchange",
    "ask_exchange",
    "conditions",
    "correction"
  ],
  "rejects": [
    "stale_quote",
    "wide_spread",
    "no_bid",
    "incomplete_pagination",
    "unavailable_entitlement"
  ]
}

That artifact is more useful than a final PnL table because another developer can inspect what the model knew, which rows it trusted, and which market-data states it rejected.

Related pages

• Quotes
• Trades
• Aggregates
• Data Sources and OPRA
• Market Data Corrections and Missing Data
• Market Hours, Timestamps, and Timezones
• Options Quotes vs Trades
• Quote vs Trade Timeline
• Why Option Quotes Matter More Than Last Price

Condition-code implementation notes

Condition fields are small, but they can decide whether a row enters a scanner or backtest. Store quote condition, trade condition, exchange id, correction, sequence number, timestamp, and raw row id when available. A later reviewer needs to know whether a print was regular, corrected, excluded, late, or useful only as context.

Use condition policy before ranking unusual activity. A high-volume print can be less informative than a clean quote update if the trade condition weakens the signal. Pair this page with Quotes, Trades, Options Flow False Positives, and Backtesting Execution Realism so each row gets accepted, labeled, or rejected for a documented reason.