API Reference

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, then open Historical Options Data API, Real-Time Options Data API, Options Chain API, and 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.

An API that is good for one workflow may be incomplete for another. A chain endpoint is enough to render a first draft UI. It is not enough to prove historical fills. For that, use the Historical Options Replay Runbook, Backtesting Execution Realism, and Quote-Aware Options Backtests 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, Market Data SIPs and Direct Feeds, and Live, Delayed, and Entitlements before writing source or freshness claims.

Endpoint completeness

A serious options stack usually needs these layers:

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:

{
  "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.

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.

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
• Live, Delayed, and Entitlements
• Market Data Access Methods
• Market Data Ingestion and Caching
• Market Hours, Timestamps, and Timezones
• Market Data Corrections and Missing Data
• Market Data Licensing and Commercial Use
• Option Chain
• Contracts
• Quotes
• Trades
• Backtesting Data Quality Checklist
• Market Data API Due Diligence Checklist