Market-data licensing affects product design. The same endpoint can be appropriate for personal research, internal professional tools, customer-facing dashboards, or commercial redistribution only when the plan, terms, exchange rules, and provider agreement support that use.
This is an engineering and procurement checklist, not contract language. Confirm final obligations with the applicable CuteMarkets agreement, exchange policy, and your legal or compliance owner. For product planning, pair this page with Pricing, Terms, Live, Delayed, and Entitlements, Data Sources and OPRA, and Market Data Access Methods.
Licensing vocabulary
| Term | Practical meaning |
|---|---|
| Personal research | Individual experimentation, prototyping, notebooks, and non-customer-facing evaluation |
| Internal professional use | Data used inside a business by employees or contractors |
| Customer display | Market data shown to customers, subscribers, users, or external viewers |
| Redistribution | Passing market data or materially similar derived data to another party or system outside the permitted use |
| Commercial use | Business use, revenue-linked product use, paid internal tools, or customer-facing workflows depending on the agreement |
| Entitlement | The plan-level right to access a product, endpoint, quote field, stream, live data, or historical depth |
| Product scope | The credential boundary between stocks, options, and paper-trading surfaces |
| Derived data | Calculations, alerts, charts, metrics, or stored outputs based on underlying market data |
| Display policy | Rules about whether and how a user interface can show live, delayed, historical, or cached values |
Use case categories
Before choosing a plan, classify the workflow:
| Use case | Typical questions |
|---|---|
| Individual backtesting | Is the data for private research? Does the workflow need historical quotes, trades, contracts, and aggregates? |
| Internal trading research | Who can access the results? Are strategy artifacts shared inside a company? Are quotes or derived signals stored? |
| Internal operations dashboard | Are employees viewing live or delayed market data? Which product scopes and quote endpoints are visible? |
| Customer-facing app | Are users seeing live, delayed, or historical prices? Is the display gated by plan and user role? |
| Alerting product | Are alerts derived from quotes, trades, chains, volume, open interest, IV, or Greeks? Are alerts sent externally? |
| Resale or redistribution | Is the product passing raw or near-raw data to customers, vendors, or downstream systems? |
| Paper trading | Are simulated fills using live quotes, delayed quotes, historical quotes, or cached data? |
Each category has different operational needs. A personal notebook might only need Historical Options Data API. A customer-facing scanner needs Real-Time Options Data API, WebSockets, plan-aware display labels, support expectations, and commercial review.
Entitlement model
An entitlement gate answers a simple question: can this key, product, plan, endpoint, and user display this field at this freshness level?
Store entitlement state beside the data:
{
"provider": "cutemarkets",
"product": "options",
"plan": "commercial",
"endpoint": "option_chain",
"freshness": "live",
"quotes": true,
"websockets": true,
"viewer_scope": "customer_display",
"reviewed_at": "2026-06-04"
}
This metadata belongs in logs, artifacts, support tickets, and user-facing freshness labels. It prevents a dashboard from showing a cached Expert quote as if a different viewer newly requested live Commercial data. It also helps engineers explain why an endpoint returns an entitlement error, an unavailable field, a delayed response, or a stale state.
See Authentication, Rate Limits, Live, Delayed, and Entitlements, and Market Data Ingestion and Caching for implementation details.
Live, delayed, historical, cached, and derived data
Freshness labels are part of commercial clarity:
- Live means the plan and endpoint support current market data for that product.
- Delayed means the response intentionally lags the live market.
- Historical means the request targets past windows or archived records.
- Cached means the application is serving stored data from a prior request.
- Backfilled means REST repaired a missed stream or missing local interval.
- Derived means the value is calculated from one or more market-data inputs.
A customer-facing app needs these labels because a chart, alert, quote, trade table, scanner score, volume/OI ratio, IV rank, or backtest result can be misunderstood without access context. The same terminology appears in Real-Time Options System Design, Real-Time Stock Data Watchlist Architecture, and Options Flow False Positives.
Quote access and display boundaries
Quotes deserve special attention. A last trade is a print; a quote is bid/ask market context. Quote access can require a different plan or product scope from trades or bars.
When planning a commercial workflow, ask:
- Are bid, ask, midpoint, spread percent, and quote age displayed to users?
- Are quotes used only internally for a fill model?
- Are quote-derived values, such as spread score or liquidity label, displayed externally?
- Does the plan include quote access for stocks, options, or both?
- Does a WebSocket subscription deliver the same fields as the REST response?
- Are delayed quote fields labeled as delayed?
- Are historical quote windows stored for replay or audit?
Use Quotes, Stock Trades and Quotes, Why Option Quotes Matter More Than Last Price, and Quote-Aware Options Backtests to keep quote terminology precise.
Customer-facing product checklist
Before putting market data into a customer-facing product, prepare a short due-diligence file:
| Area | Evidence to collect |
|---|---|
| Product scope | Stocks, options, paper trading, or combined stock/options workflow |
| Access methods | REST, WebSocket, cache, export, or vendor flat file |
| Freshness | Live, delayed, historical, cached, backfilled, stale, unavailable |
| Display | Which raw and derived fields are visible to external users |
| Storage | Which values are stored, for how long, and in what artifact |
| Redistribution | Whether raw or near-raw records leave the product boundary |
| User roles | Internal admin, customer user, contractor, public visitor |
| Support path | Who handles entitlement errors, missing data, outages, and billing questions |
| Documentation | Links to Pricing, Terms, Status, Support, and endpoint docs |
The file is useful even before formal review because it makes hidden assumptions visible to engineering, product, and support teams.
Procurement questions
Use these questions when comparing providers:
- What exact asset classes and endpoint groups are included?
- Are options, stocks, and quotes priced or entitled separately?
- What is live, delayed, historical, cached, or unavailable on each plan?
- Are WebSockets included, limited, or commercial-only?
- Are flat files, exports, or bulk archives included?
- Is customer display allowed on the plan being evaluated?
- Is internal professional use different from individual research?
- Are derived alerts, rankings, or scanner outputs covered?
- What support channel handles data-quality tickets?
- How are outages, corrections, late prints, or missing quote windows communicated?
- Does the provider expose an OpenAPI spec or other machine-readable docs?
- Does the agreement cover the actual product architecture?
For CuteMarkets comparison flows, link this checklist with Options Data API Evaluation Framework, Options Data Vendor Checklist, Options Data Provider Evaluation, Stock Data Provider Evaluation, and Market Data API Due Diligence Checklist.
Engineering controls
Commercial-use risk often appears as an engineering bug:
- a cached live quote shown to a user without a freshness label
- an internal-only field exposed in an external API response
- a WebSocket reconnect replayed as live state
- a stock quote plan assumed to include option quotes
- a derived scanner score that effectively republishes raw market fields
- a historical backtest artifact downloaded by a user who is not entitled to the underlying quote data
- a support export that includes raw response payloads
Add controls at the boundary:
- product-scoped API keys
- server-side entitlement checks
- user-role checks before display
- freshness labels in response objects
- audit logs for quote and stream access
- field allowlists for customer-facing APIs
- cache partitioning by plan and product
- separate internal artifacts from public exports
These controls fit naturally with Authentication, OpenAPI, Market Data Ingestion and Caching, and Paper Trading API.