# Option Quote and Trade Conditions

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](/docs/quotes), [Trades](/docs/trades), [Quotes, Trades, and Aggregates](/docs/quotes-trades-aggregates-semantics), [Data Sources and OPRA](/docs/data-sources-opra), [Market Data Corrections and Missing Data](/docs/market-data-corrections-missing-data), and [Options Data Provider Evaluation](/docs/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

| Term | Meaning | Related CuteMarkets workflow |
| --- | --- | --- |
| NBBO-style quote | A top-of-book bid/ask record with bid price, ask price, displayed size, exchange ids, and timestamp context. | [Quotes](/docs/quotes), [Historical Options Quotes API](/historical-options-quotes-api), and [quote-aware fills](/blog/quote-aware-options-fills-research). |
| Sale condition | A code or label attached to a trade print that explains the circumstances of the execution. | [Trades](/docs/trades), [Options Trades API](/options-trades-api), and [missing-data checks](/docs/market-data-corrections-missing-data). |
| Quote condition | A condition attached to a quote update that can affect whether the bid/ask row is eligible for a decision. | [Quotes](/docs/quotes), [Real-Time Options System Design](/docs/real-time-options-system-design), and [live entitlements](/docs/live-delayed-entitlements). |
| Exchange id | A numeric or symbolic participant identifier for the venue associated with a bid, ask, or trade. | [Data Sources and OPRA](/docs/data-sources-opra) and [Market Data SIPs and Direct Feeds](/docs/market-data-sips-direct-feeds). |
| Correction indicator | A field that marks whether a trade row has correction context. | [Trades](/docs/trades), [Aggregates](/docs/aggregates), and [Backtesting Data Quality Checklist](/docs/backtesting-data-quality-checklist). |
| Sequence number | A provider or feed sequence field that helps order events inside a symbol stream. | [WebSockets](/docs/websockets), [Market Hours and Timestamps](/docs/market-hours-timestamps-timezones), and replay artifacts. |
| SIP timestamp | The timestamp associated with SIP receipt or dissemination. | [Data Sources and OPRA](/docs/data-sources-opra), [Quotes](/docs/quotes), and [Trades](/docs/trades). |
| Participant timestamp | The timestamp associated with the exchange or participant when available. | [Trades](/docs/trades) and [Market Hours and Timestamps](/docs/market-hours-timestamps-timezones). |

## 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](/docs/backtesting-execution-realism), [Options Flow False Positives](/docs/options-flow-false-positives), and [Unusual Options Activity Scanner Model](/docs/unusual-options-activity-scanner-model) all keep quote freshness, spread, trade context, and reject labels visible.

## Quote rows versus trade rows

| Question | Use quotes | Use trades |
| --- | --- | --- |
| What market was available near a decision timestamp? | Yes. Use bid, ask, size, quote timestamp, and exchange ids. | Not by itself. A print can be stale or not available later. |
| Did the contract actually trade? | No. A quote can be active with no recent prints. | Yes. Use price, size, exchange, timestamp, and condition context. |
| Can a backtest buy realistically? | Use ask-side, midpoint, near-side, or policy-specific fill rules from quotes. | Use trades to validate activity, not as the only execution source. |
| Can a bar be trusted? | Use quotes to inspect tradability around the bar. | Use trades and condition eligibility to support aggregate construction. |
| Can a scanner alert escalate? | Use spread, quote age, and size filters. | Use print size, premium, frequency, and condition context. |
| Can a dashboard show current state? | Use latest quote with freshness labels where the plan allows it. | Use last trade only with timestamp and quote pairing. |

## Fields to preserve in artifacts

When an application stores a [historical replay artifact](/docs/historical-options-replay-runbook), a scanner alert, a support ticket, or a paper-trading audit row, preserve the fields that explain the decision.

| Artifact field | Why it belongs in the record |
| --- | --- |
| `options_ticker` | Keeps the exact OCC-style contract identity tied to the row. |
| `endpoint` | Distinguishes chain, quote, trade, aggregate, snapshot, and latest endpoints. |
| `timeframe` and `delay_minutes` | Shows whether the value was live, delayed, or historical. |
| `sip_timestamp` | Anchors the row to market-data event time. |
| `participant_timestamp` | Preserves exchange-side time when available. |
| `bid_price` and `ask_price` | Keeps execution context separate from last sale. |
| `bid_size` and `ask_size` | Exposes visible size and one-sided markets. |
| `bid_exchange` and `ask_exchange` | Records venue context for the displayed quote. |
| `price` and `size` | Stores trade print economics and contract count. |
| `exchange` | Records trade venue context. |
| `conditions` | Preserves sale-condition context for filtering and review. |
| `correction` | Marks corrected or correction-related trade rows where supplied. |
| `sequence_number` | Helps audit event ordering and stream gaps. |
| `request_id` | Lets support and engineering trace the API response. |
| `next_url` or `page` | Proves pagination completeness for heavy windows. |
| `reject_reason` | Explains why a row was skipped, widened, delayed, or excluded. |

## 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.

| Policy area | Practical rule |
| --- | --- |
| Fill source | Use [quotes](/docs/quotes) for entry and exit evidence. Store side-specific bid/ask assumptions. |
| Trade validation | Use [trades](/docs/trades) for activity and tape review. Do not treat every last sale as executable fill evidence. |
| Empty windows | Record an empty-window reject or a documented widen-window rule. |
| Wide spreads | Reject or penalize contracts above the allowed spread percent. |
| No-bid exits | Reject, heavily penalize, or route to a specific liquidation policy. |
| Corrections | Preserve correction fields and exclude rows that the strategy policy treats as ineligible. |
| Condition codes | Preserve raw condition arrays and apply documented include/exclude rules before volume, VWAP, or alert scoring. |
| Timestamp ordering | Use row-level timestamps and avoid same-bar fills unless the order was already active. |
| Pagination | Follow `next_url` until the requested quote or trade window is complete. |

This policy belongs beside [Options Contract Selection](/docs/options-contract-selection), [Backtesting Engine Loop](/docs/backtesting-engine-loop), [Backtesting Data Model](/docs/backtesting-data-model), and [Backtesting Robustness](/docs/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.

| Scanner label | Required evidence |
| --- | --- |
| High-volume candidate | Same-day volume, prior open interest, expiration, strike, side, and contract identity. |
| Large-premium candidate | Trade size, price, estimated premium, timestamp, and condition context. |
| Tight-quote candidate | Bid, ask, spread percent, quote age, and displayed size. |
| Wide-spread reject | Bid/ask width exceeds the scanner policy. |
| No-bid reject | Exit-side bid is missing or unusable. |
| Trade-review required | Trade print exists, but quote direction, conditions, or multi-leg context remain unresolved. |
| Stale-last-price warning | Last trade timestamp is far away from current quote or scanner timestamp. |
| Entitlement warning | The plan does not include live quote or stream behavior for the displayed claim. |

Use those labels with [Unusual Options Activity](/unusual-options-activity), [Options Chain API](/options-chain-api), [Options Liquidity Scanner](/options-liquidity-scanner), [Put/Call Ratio API](/put-call-ratio-api), and [Options Flow False Positives](/docs/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](/blog/market-data-api-due-diligence-checklist), [Options Data Vendor Checklist](/options-data-vendor-checklist), [Best Options Data APIs](/best-options-data-apis), and [Compare Options Data APIs](/compare).

## Example replay note

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

```json
{
  "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](/docs/quotes)
- [Trades](/docs/trades)
- [Aggregates](/docs/aggregates)
- [Data Sources and OPRA](/docs/data-sources-opra)
- [Market Data Corrections and Missing Data](/docs/market-data-corrections-missing-data)
- [Market Hours, Timestamps, and Timezones](/docs/market-hours-timestamps-timezones)
- [Options Quotes vs Trades](/options-quotes-vs-trades)
- [Quote vs Trade Timeline](/quote-vs-trade-timeline-options)
- [Why Option Quotes Matter More Than Last Price](/blog/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](/docs/quotes), [Trades](/docs/trades), [Options Flow False Positives](/docs/options-flow-false-positives), and [Backtesting Execution Realism](/docs/backtesting-execution-realism) so each row gets accepted, labeled, or rejected for a documented reason.