Read this page with Pricing, Rate Limits and Plans, Authentication, Real-Time Options Data API, and Market Data Licensing and Commercial Use.
Market-data freshness is a product feature, a compliance concern, and an engineering variable. A delayed quote can be useful for education or research, but it should never be labeled as live data in a UI, alert, stream, or backtest artifact.
Use this guide when choosing a plan, designing logs, or explaining why the same endpoint family can behave differently across API keys.
Quick answer
CuteMarkets separates Stocks API and Options API subscriptions. Free and Developer plans are delayed. Expert and Commercial plans include live data, quote endpoints, and WebSocket streams for the subscribed product. Applications need to display and log whether data is live, delayed, or historical, and plan access needs to be treated as part of the data contract.
Freshness categories
| Category | What it means | Typical use |
|---|---|---|
| Live | Current market-data access under the subscribed product and plan. | Production dashboards, scanners, alerts, and streaming workflows. |
| Delayed | Market data intentionally lagged by the plan or entitlement. | Evaluation, education, delayed dashboards, and non-live research. |
| Historical | Rows requested for a past timestamp window. | Backfills, event studies, research, and backtests. |
| Cached | Previously retrieved data stored by the application. | Fast UI loads, replay, and reproducible research artifacts. |
The same screen can contain several categories. A current stock snapshot, an option chain snapshot, and a historical option quote window may all be visible together. Label them separately.
Product entitlement boundaries
Stocks and options are separate products. A Stocks API key does not imply Options API access, and an Options API key does not imply Stocks API access. Quote endpoints and WebSocket streams are also plan-sensitive.
When an integration fails, check entitlement before debugging data availability:
- Is the API key active?
- Is the key subscribed to the correct product?
- Does the selected plan include quotes?
- Does the selected plan include live data or only delayed data?
- Does the selected plan include WebSocket access?
- Is the requested timestamp inside the plan lookback?
UI and log design
User-facing interfaces need visible freshness. If a quote is delayed, say delayed. If a value is historical, say historical. If a row comes from a backfilled cache, keep the source request and timestamp bounds in an audit log.
For logs, store:
| Field | Why |
|---|---|
product | Stocks or options. |
plan | Explains available endpoints and freshness. |
endpoint | Quotes, trades, snapshots, bars, or reference. |
request_timestamp | When the application asked. |
row_timestamp | When the market-data row occurred. |
freshness | Live, delayed, historical, or cached. |
delay_minutes | Useful when returned by the API. |
request_id | Support and reproducibility. |
Backtesting implications
Backtests are historical by design, but quote availability, lookback, and endpoint access still shape what data can be retrieved. Do not let a backtest silently switch from quotes to last trades because the key lacks quote access. The run should fail, skip, or label itself as a lower-fidelity variant.
If a research run mixes cached historical data with new pulls, record cache version, endpoint, timestamp bounds, and any plan assumptions. That makes the result debuggable when a future replay produces different coverage.
Official references
Related CuteMarkets docs
- Rate Limits and Plans
- WebSockets
- Data Sources and OPRA
- Market Data SIPs and Direct Feeds
- Backtesting Data Quality Checklist
Entitlements affect every real-time integration, so compare this page with Market Data Access Methods, WebSockets, and Rate Limits. Plans should distinguish live, delayed, historical, REST, WebSocket, OPRA, SIP, direct-feed, redistribution, and commercial-use permissions.
Entitlement implementation notes
Live, delayed, historical, and unavailable states need visible labels in products. A WebSocket connection can be healthy while the current key still lacks live quote entitlement. A REST response can be valid while the payload is delayed. Store product scope, plan class, delay state, quote entitlement, timestamp freshness, and request id with each market-data row.
Use this page with Authentication, WebSockets, Rate Limits and Plans, and Market Data Licensing and Commercial Use. A customer-facing dashboard should not let delayed options quotes look like live NBBO. A research notebook can accept delayed context when it labels the state and avoids live execution claims.
Additional implementation review
Review the live and delayed data workflow as a sequence of named data objects, not as a single helper call. The implementation should preserve product scope, live entitlement, delayed entitlement, quote freshness, timestamp semantics, plan gate, and error envelope. Those fields make support tickets, CI fixtures, and replay notebooks easier to compare because every step can point to the exact request and response that created the displayed value.
The main failure mode is that a UI can present delayed or unavailable data as live market state and make an alert look more current than it is. Before promoting the workflow, run one concrete example through discovery, retrieval, display, logging, and error handling. Keep the resulting artifact beside the code path so future changes can prove they still use the same terminology and the same market-data assumptions.