# Options Data Provider Evaluation

Choosing an options data provider is not the same as choosing a generic market data API. Options have listed expirations, contract identity, wide and changing spreads, multiple exchanges, sparse prints, stale last prices, corporate-action adjustments, and plan-specific entitlement rules. A provider can look complete because it has an option chain endpoint and still fail the first serious backtest or scanner.

Use this page as a technical evaluation checklist before comparing vendors, plans, or endpoint names.

For the CuteMarkets evaluation path, start with [Options Data API](/options-data-api), then open [Historical Options Data API](/historical-options-data-api), [Real-Time Options Data API](/real-time-options-data-api), [Options Chain API](/options-chain-api), and [Best Options Data APIs](/best-options-data-apis). The terminology in those resources stays consistent with this guide: OPRA, OCC option symbols, NBBO-style quotes, bid/ask spread, quote age, DTE, IV, Greeks, open interest, point-in-time contracts, `as_of`, aggregates, WebSockets, entitlements, and reject reasons.

## The evaluation starts with the workflow

Start with the job you are trying to build. Do not start with a vendor feature matrix.

| Workflow | Questions to resolve first | Data objects required |
| --- | --- | --- |
| Live chain scanner | Which contracts are visible now, which rows are fresh, and which rows are liquid enough to show? | Expirations, chain snapshots, Greeks, IV, OI, latest quote, latest trade, snapshots |
| Historical backtest | Which contracts existed at the decision time and what bid/ask market was available? | Contracts with `as_of`, quotes, trades, aggregates, expirations |
| Earnings replay | What did the surface imply before the event and what was tradable after it? | Event timestamp, expirations, chains, quotes, trades, IV, Greeks, rejects |
| Dashboard or product UI | What should a user see, how fresh is it, and which fields are entitled? | Snapshots, chains, quotes by plan, trades, bars, reference data |
| Paper trading or simulation | What did the strategy observe, what fill rule did it use, and why were trades rejected? | Signal bars, selected contracts, quote windows, fills, rejects, request logs |

An API that is good for one workflow may be incomplete for another. A [chain endpoint](/options-chain-api) is enough to render a first draft UI. It is not enough to prove historical fills. For that, use the [Historical Options Replay Runbook](/docs/historical-options-replay-runbook), [Backtesting Execution Realism](/docs/backtesting-execution-realism), and [Quote-Aware Options Backtests](/blog/quote-aware-options-backtests-bid-ask-rejects) material together.

## Coverage and provenance

Ask where the data comes from and how the provider describes the route from exchange to API. For U.S. listed options, the practical vocabulary includes OPRA, exchanges, quotes, trades, NBBO-style consolidated fields, condition codes, timestamps, and entitlements. A provider does not need to expose every upstream detail publicly, but it should be able to explain the source model and the limits of what it normalizes.

Evaluation questions:

- Does the provider say whether the options data is OPRA-originating or otherwise sourced?
- Does it distinguish quotes from trades?
- Does it explain exchange identifiers, participant context, or condition codes where relevant?
- Does it identify whether fields are live, delayed, historical, cached, or plan-gated?
- Does it explain timestamp units and timezone conversion?
- Does it document missing rows, empty aggregate intervals, and pagination?

The answer should be concrete. "Institutional-grade data" is not a source model. For CuteMarkets terminology, compare [Data Sources and OPRA](/docs/data-sources-opra), [Market Data SIPs and Direct Feeds](/docs/market-data-sips-direct-feeds), and [Live, Delayed, and Entitlements](/docs/live-delayed-entitlements) before writing source or freshness claims.

## Endpoint completeness

A serious options stack usually needs these layers:

| Layer | Minimum expectation | Why it matters |
| --- | --- | --- |
| Expirations | Listed dates by underlying | Prevents hard-coded weekly or monthly assumptions |
| Contracts | Reference records and historical `as_of` discovery | Prevents stale-contract and future-listing leakage |
| Chains | Current contract surface by underlying and expiration | Supports scanners, strike tables, and candidate selection |
| Snapshots | One-contract current state | Supports selected-leg panels and live watchlists |
| Quotes | Bid/ask history and latest quote where entitled | Supports spread checks and fill realism |
| Trades | Time-and-sales prints and last trade | Supports activity validation and tape context |
| Aggregates | OHLC bars, VWAP, previous close, open/close | Supports charts and signal context |
| Greeks and IV | Sensitivity fields where available | Supports risk filters and volatility workflows |
| Open interest | Contract participation context | Supports liquidity and expiry concentration filters |

If a provider has only snapshots and chains, it may be usable for a simple UI but weak for research. If it has trades but not quotes, last-price backtests may look better than real executable markets. If it has historical prices but not historical contracts, the study can leak today's contract universe into the past.

## Plan and entitlement review

Market data plans often differ by live access, delayed access, quote endpoints, WebSockets, request limits, lookback, professional use, commercial display, and redistribution. This is not fine print. It changes what your product can legally and technically do.

Create a plan note in your application config:

```json
{
  "provider": "cutemarkets",
  "product": "options",
  "plan": "expert",
  "freshness": "live",
  "quotes": true,
  "websockets": true,
  "commercial_display": false,
  "historical_lookback": "plan-specific",
  "reviewed_at": "2026-06-04"
}
```

Do not hide entitlement assumptions in code comments. Surface them in logs, dashboards, and support runbooks so users understand why a quote field is present, delayed, or unavailable.

## Timestamp and timezone checklist

Options research breaks when timestamps are vague. Every provider evaluation should include a small timestamp test.

1. Request a known intraday quote window.
2. Confirm the timestamp unit and timezone.
3. Convert it to the market session timezone.
4. Check whether the row ordering is stable.
5. Check pagination for the same window.
6. Confirm how empty windows are represented.
7. Store the request URL and response metadata beside the result.

For live workflows, add last-seen event timestamps and reconnect timestamps. For historical workflows, add decision timestamps, entry windows, exit windows, and quote-age thresholds.

## Failure modes to test

The fastest way to learn whether a provider is usable is to test edge cases deliberately.

| Failure mode | Test | Good response from the workflow |
| --- | --- | --- |
| No listed expiration | Request a non-listed date | Return a clear empty result or error; do not guess a date |
| Missing quote window | Request quotes around an inactive period | Preserve the missing-data reason and reject the fill |
| Wide spread | Request a thin contract | Compute spread percent and block the contract if over policy |
| Stale last price | Compare last trade and quote timestamp | Prefer quote evidence for fills and label stale trades |
| Pagination incomplete | Stop after the first chain page | Mark the chain incomplete and prevent rankings that assume full coverage |
| Plan-gated field | Request quotes on a non-quote plan | Show entitlement state instead of silently degrading the model |
| Adjusted contract | Inspect post-split or special-dividend contracts | Preserve shares per contract, deliverable notes, and exact OCC identity |

These tests are not academic. They are the difference between a product that fails loudly and a backtest that silently overstates edge.

## Comparison method

When comparing CuteMarkets, Massive, Intrinio, Databento, ThetaData, or another provider, avoid winner-take-all claims. Use a workflow scorecard.

| Criterion | How to score it |
| --- | --- |
| Source clarity | Does the provider explain source, exchange, OPRA/SIP, or feed context? |
| Object coverage | Are contracts, chains, quotes, trades, aggregates, expirations, Greeks, IV, and OI available? |
| Historical correctness | Can it rebuild a historical contract universe and quote window? |
| Live operations | Does it support live snapshots, streams, reconnect policies, and freshness labels? |
| Access method fit | Does the workflow need REST snapshots, historical windows, WebSockets, flat files, local caches, or backfills? |
| Ingestion readiness | Can the team store cache keys, pagination completeness, rate-limit budget, source requests, and replay manifests? |
| Buyer clarity | Are pricing, quote access, commercial use, and support boundaries easy to understand? |
| Developer ergonomics | Are docs, examples, pagination, response envelopes, and error behavior clear? |
| Research integrity | Does the workflow make rejects, missing data, and fill assumptions visible? |

Massive is strong at infrastructure and endpoint documentation. Intrinio is strong at broad product packaging and buyer support surfaces. CuteMarkets should be evaluated on its narrower strength: quote-aware, contract-aware options workflows for developers who need auditable research and live tools.

## Red flags

Be cautious when a page or sales deck:

- says "options price" without distinguishing quote, trade, midpoint, snapshot, and aggregate
- shows a chain but never explains historical contract selection
- offers "historical options data" without `as_of` or equivalent point-in-time language
- does not mention live versus delayed data by plan
- does not document pagination or missing data
- treats open interest, volume, and liquidity as the same thing
- has comparison claims without sources or last-reviewed dates
- cannot explain whether customer-facing display or redistribution is allowed

## Related CuteMarkets docs

- [Data Sources and OPRA](/docs/data-sources-opra)
- [Live, Delayed, and Entitlements](/docs/live-delayed-entitlements)
- [Market Data Access Methods](/docs/market-data-access-methods)
- [Market Data Ingestion and Caching](/docs/market-data-ingestion-and-caching)
- [Market Hours, Timestamps, and Timezones](/docs/market-hours-timestamps-timezones)
- [Market Data Corrections and Missing Data](/docs/market-data-corrections-missing-data)
- [Market Data Licensing and Commercial Use](/docs/market-data-licensing-commercial-use)
- [Option Chain](/docs/option-chain)
- [Contracts](/docs/contracts)
- [Quotes](/docs/quotes)
- [Trades](/docs/trades)
- [Backtesting Data Quality Checklist](/docs/backtesting-data-quality-checklist)
- [Market Data API Due Diligence Checklist](/blog/market-data-api-due-diligence-checklist)