CuteMarkets options endpoints are built around OPRA-originating U.S. listed options market data. OPRA, the Options Price Reporting Authority, is the securities information processor that disseminates consolidated last-sale and quotation information from SEC-approved U.S. options exchanges.
This guide explains where options trades and quotes come from, why quotes and trades can disagree, and which source questions matter when evaluating an options data API.
Quick answer
OPRA is the consolidated reporting layer for U.S. exchange-listed options trades and quotes. CuteMarkets exposes that market-data layer through developer-friendly REST and WebSocket APIs, then adds product behavior such as authentication, response envelopes, pagination, plan-aware freshness, and normalized endpoint shapes.
Stocks and options are separate data products in CuteMarkets. OPRA context applies to the options side; stock endpoints use the Stocks API product and separate Stocks API keys.
What OPRA contributes
OPRA receives and disseminates options market information from participant exchanges. The most important objects for developers are:
| Object | What it means | CuteMarkets workflow |
|---|---|---|
| Last-sale reports | Executed option trades, including price, size, timestamps, exchange identifiers, and condition context. | Trades and trade-derived Aggregates. |
| Quotations | Bid and ask updates across listed option series. Quote traffic is usually much heavier than trade traffic. | Quotes, chain quote fields, spread checks, and quote-aware backtests. |
| Participant/exchange context | Exchanges contributing option markets and messages. | Exchange id fields on quote and trade rows. |
| Administrative/reference context | Data needed to identify listed series and support market-data processing. | Contracts, expirations, snapshots, and symbol workflows. |
Why this matters in applications
An option is not a stock ticker with one clean price. One contract can have a stale last trade, a live bid/ask quote, an implied-volatility estimate, and an aggregate bar that all describe different things. A good application labels the field it is using instead of collapsing everything into "the option price."
For dashboards, show whether a value comes from a quote, trade, bar, snapshot, or derived calculation. For backtests, store the endpoint, timestamp filters, selected contract, quote age, spread, and reject reason. For scanners, rank contracts only after you know whether the data object supports the decision being made.
Quotes versus trades
Trades show what printed. Quotes show the market that was being advertised. Both can be true while pointing to different prices.
Use trades for volume, tape review, aggregate bars, and printed activity. Use quotes for executable bid/ask context, spread checks, fill assumptions, and current tradability. When an options backtest uses last trade as a fill proxy, it can accidentally price against stale or non-executable information.
Live, delayed, and plan-aware data
Plan behavior matters because a user can receive the same endpoint family with different freshness. Free and Developer plans are delayed. Expert and Commercial plans include live data, quote endpoints, and WebSocket streams for the subscribed product.
When building a client, keep freshness visible in logs and UI. Store the timeframe, delay_minutes, and timestamp fields where they are returned. A delayed quote can be useful for research or evaluation, but it should not be labeled as a live market.
Data-source checklist
Before building around any options data API, answer these questions:
- Does the workflow need quotes, trades, aggregates, snapshots, or all of them?
- Is the quote endpoint live, delayed, or unavailable on the selected plan?
- Are timestamps stored at the row level, not just at the request level?
- Are exchange ids, condition codes, sequence fields, and corrections preserved when needed?
- Does the application distinguish last sale, bid, ask, midpoint, and derived values?
- Are redistribution, display, non-display, and customer-facing use cases allowed by the selected subscription and agreements?
- Can the workflow reconstruct historical contract availability before requesting quotes or trades?