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 entitlement still matters because quote availability, lookback, and endpoint access 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.