Network access was denied, so I cannot fetch pages to verify. I’ll cite only well-established documentation URLs I’m confident of. Here is the article:
Use real-time market data when a decision has to be made within seconds of a price change: order routing, live dashboards, alerting, and anything shown on air or on screen as current. Use historical data for everything else: backtesting, research, reporting, charting past periods, and training models. Most working systems need both, wired through two different API patterns: a streaming WebSocket for the live feed and a paginated REST endpoint for the archive.
What counts as real-time, delayed, and historical?
In US equities, “real-time” means the data arrives within milliseconds of the trade or quote. The baseline is the consolidated tape, produced by the Securities Information Processors under the Consolidated Tape Association and the UTP plan. The SEC’s Regulation NMS adopting release defines the rules that require trade and quote data to be consolidated and made available. Exchanges also sell direct feeds that are faster than the SIP by hundreds of microseconds to a few milliseconds, which matters only for latency-sensitive trading.
“Delayed” data is the same feed held back, normally 15 minutes, and is usually free because exchange licensing fees drop sharply once the delay is applied.
“Historical” data is the stored record: tick-level trades and quotes, or aggregated bars at one-minute, hourly, or daily intervals. Daily bars for a decade typically cost nothing; full tick history across all US venues is a terabyte-scale product that vendors price per symbol-day or per month.
When does real-time data actually earn its cost?
- Execution. Any order logic that compares a live quote to a limit needs real-time data. Delayed data here produces fills at prices that no longer exist.
- Risk and alerts. Position monitoring, stop triggers, and threshold alerts need sub-second updates during market hours.
- Live display. Tickers on a trading floor, a broadcast lower-third, or a client app that advertises “live” prices. Showing 15-minute-delayed data labelled as live breaches most exchange display agreements.
If the output is a chart someone reads later, a nightly report, or a weekly explainer video, real-time data adds licensing cost and engineering complexity without changing the result.
When is historical data the right tool?
- Backtesting. A strategy must be tested on the data it would have seen at the time, including delisted tickers. Datasets that drop dead companies carry survivorship bias and overstate returns.
- Research and modelling. Correlations, volatility estimates, seasonality, and machine-learning features all come from the archive.
- Content and reporting. Explainer videos, earnings recaps, and year-in-review pieces use adjusted daily closes. Confirm whether the feed adjusts for splits and dividends, because unadjusted series show false price gaps.
How do the APIs differ in practice?
| Need | API pattern | Typical limits |
|---|---|---|
| Live trades and quotes | WebSocket subscription per symbol | Symbol caps per connection, reconnect handling required |
| Latest snapshot | REST GET, polled | Per-minute request quotas |
| Bars and tick history | REST GET with date range and pagination | Rows per page, often 1,000 to 50,000 |
| Bulk archive | Flat-file download or batch job | Priced per symbol-day or dataset |
Concrete examples. Alpaca’s market data API serves its free tier from the IEX exchange feed, which covers a small share of US volume, and reserves the full SIP feed for its paid plan. Polygon’s documentation splits REST aggregate endpoints for history from WebSocket channels for live trades, quotes, and per-second bars. Alpha Vantage offers daily and intraday series over plain REST with a low daily request quota on its free key, which suits reporting but not live use. In crypto, Binance’s spot API publishes both a klines endpoint capped at 1,000 candles per request and WebSocket streams for live trades and order-book depth.
How do you combine the two without errors?
Backfill from the historical endpoint up to a timestamp, open the WebSocket, then replay any messages whose timestamps fall after the backfill cutoff. Store the exchange timestamp, not your receive time. Keep bar construction identical in both paths, or live and historical charts will disagree at the seam.
Licensing is the usual surprise. Real-time display to the public requires exchange agreements and per-user fees that delayed and historical data do not. For a production company, that decides the question: a live ticker in a client’s app is a licensing project, while a chart in a video is a data pull.
