Market data access method is the delivery shape of the data: REST request, WebSocket stream, historical replay query, export, cache, or vendor flat file. The choice changes latency, cost, pagination, data completeness, entitlement handling, and the way engineers debug missing rows.
CuteMarkets is built around REST APIs, authenticated WebSocket streams, OpenAPI documentation, and local application caches created by the customer. This guide explains those access methods and also defines flat files, bulk exports, and local caches so a developer can compare CuteMarkets with providers that sell downloadable archives.
Start from the Options Data API, Stocks Data API, OpenAPI docs, WebSocket docs, and Rate Limits before designing an ingestion layer.
Core terms
| Term | Meaning | Typical CuteMarkets path |
|---|---|---|
| REST snapshot | A synchronous request for the current or requested state of an object | Option Chain, Stock Snapshots, Contract Snapshot |
| Historical REST window | A request bounded by ticker, contract, date, timestamp, or as_of | Contracts, Quotes, Trades, Aggregates |
| WebSocket stream | A persistent authenticated connection for live event updates | WebSockets, Real-Time Options System Design |
| Pagination cursor | A continuation link or token used when a result set is larger than one page | OpenAPI, Rate Limits |
| Backfill | A REST request used to repair or complete a missing historical interval | Historical Options Replay Runbook |
| Local cache | Customer-owned storage for responses, bars, chains, quotes, manifests, and replay artifacts | Backtesting Data Model |
| Flat file | A downloadable batch file such as CSV, parquet, or compressed daily data from a vendor archive | Use provider-specific checks in Options Data Provider Evaluation |
| Entitlement gate | A plan, product, quote, live, delayed, or commercial-use boundary checked before access | Live, Delayed, and Entitlements |
REST access
REST is the right starting point for almost every market-data integration. A request has a URL, parameters, headers, a response envelope, and a retry policy. That makes it reproducible and easy to log.
Use REST when the workflow needs:
- a current option chain for an underlying and expiration
- a contract snapshot after a scanner selects an OCC symbol
- listed expirations before requesting chains
- point-in-time contract discovery with
as_of - historical option quotes around an entry or exit timestamp
- stock snapshots, trades, quotes, aggregates, or indicators
- a completed-bar backfill after a stream disconnect
- a deterministic request artifact for a backtest
REST is especially important for backtesting because the research artifact can store the exact URL, query parameters, timestamp bounds, response status, request_id, pagination state, plan label, and reject reason. That is why the Historical Options Data API, Options Backtesting API, and Backtesting Data Quality Checklist all use REST terminology heavily.
WebSocket access
WebSockets are useful when a product needs ongoing updates without polling every row. They are not a substitute for REST. A live scanner or dashboard usually initializes with REST, subscribes to streams where the plan allows it, and repairs gaps with REST backfills.
Use WebSockets when the workflow needs:
- live dashboard state
- continuous watchlist updates
- scanner alert generation
- lower-latency state changes than polling
- explicit reconnect and freshness logging
- a stream audit trail per subscription
Every WebSocket consumer needs operational vocabulary: connection opened, authenticated, subscribed, last event timestamp, heartbeat, reconnect count, disconnect reason, stale threshold, backfill window, and entitlement label. The Real-Time Options Data API, Real-Time Stock Data API, and Live, Delayed, and Entitlements pages are the product-level companions to the WebSocket docs.
Historical REST windows
Historical REST windows are the workhorse for research. They turn a broad phrase like "historical options data" into a concrete request:
curl "https://api.cutemarkets.com/v1/options/quotes/O:SPY260619C00550000/?timestamp.gte=2026-06-04T15:30:00Z×tamp.lt=2026-06-04T15:35:00Z&limit=1000" \
-H "Authorization: Bearer YOUR_API_KEY"
Store the contract ticker, underlying, expiration, side, strike, decision timestamp, quote window, entry policy, exit policy, adjusted flag where relevant, pagination cursor, and missing-data behavior.
For options, use historical REST windows with Contracts, Quotes, Trades, Aggregates, and Option Symbols and Contract Identity. For stocks, use Stock Trades and Quotes, Stock Aggregates and Indicators, and Stock and Options Data Join Workflow.
Flat files and bulk archives
Flat files fit teams that need very large historical archives, offline warehouse loads, or nightly batch processing. They can be CSV, parquet, compressed JSON, or vendor-specific files delivered through a storage bucket. A flat-file product can fit a quant warehouse and still be awkward for an interactive scanner or product UI.
When evaluating any flat-file offering, record:
- file format and compression
- partitioning by date, ticker, asset class, or exchange
- timestamp precision and timezone
- symbol format and contract identity rules
- quote, trade, aggregate, and reference-data separation
- condition codes and missing-data representation
- update frequency and late correction policy
- storage cost and egress cost
- license terms for internal use, display, and redistribution
CuteMarkets product docs do not position flat files as the primary access path. If a workflow mainly requires warehouse-scale archives, include that requirement in the provider scorecard and compare it with the REST and WebSocket strengths described in Options Data Provider Evaluation, Stock Data Provider Evaluation, and Best Options Data APIs.
Local caches
A local cache becomes part of the data contract in backtests, scanners, and dashboards.
A useful cache key includes:
- provider name
- product scope, such as stocks or options
- endpoint name
- ticker, underlying, or OCC option symbol
- timestamp bounds
- expiration date, strike, side, DTE bucket, and
as_ofwhere relevant - adjusted or unadjusted state
- plan and entitlement state
- response schema version
- pagination cursor version
For example, an options replay cache can store chain pages, selected contracts, quote windows, trade windows, aggregate bars, open interest, Greeks, IV, rejects, and fill decisions. That same artifact can link to Options Chain Scanner Architecture, Historical Options Replay Runbook, and Backtesting Execution Realism.
Choosing an access method by workflow
| Workflow | Access method mix | Notes |
|---|---|---|
| Live options chain scanner | REST initialization, optional WebSocket updates, REST quote/trade drill-down | Begin with Options Chain API, then validate candidates with Historical Options Quotes API when needed |
| Historical event replay | Historical REST windows and local artifacts | Store event timestamp, selected OCC contracts, quote windows, trades, aggregate bars, rejects, and plan labels |
| Stock watchlist | REST snapshots, optional WebSocket updates, REST backfills | Keep stock trades, stock quotes, aggregates, and reference data separate |
| Customer dashboard | REST snapshots, plan labels, freshness labels, support runbook | Link UI rows to Live, Delayed, and Entitlements and Pricing assumptions |
| Quant warehouse | Vendor flat files or customer-built REST ingestion | Evaluate update frequency, storage format, corrections, licensing, and replay semantics |
| Paper trading bot | REST state checks, live stream where entitled, local state log | Pair Paper Trading API with Paper Trading Bot Data Stack |
Evaluation checklist
Before choosing a provider or writing a wrapper, answer these questions:
- Which data objects are required: reference, chain, contract, snapshot, quote, trade, aggregate, indicator, open interest, Greeks, or IV?
- Which access methods are required: REST, WebSocket, flat file, local cache, or all of them?
- Which parts are live, delayed, historical, cached, quote-gated, or unavailable by plan?
- How does pagination work for large chains, dense quote windows, and multi-day backfills?
- How are empty intervals represented?
- Can reconnect gaps be repaired with REST?
- Can every scanner alert link to source requests or subscriptions?
- Can every backtest fill link to a quote window and reject policy?
- Does the intended use involve personal research, internal commercial use, customer display, resale, or redistribution?
The access method decision belongs beside the provider decision. For a wider buyer workflow, continue with Market Data Ingestion and Caching, Market Data Licensing and Commercial Use, Options Data Vendor Checklist, and Market Data API Due Diligence Checklist.