The most common mistake when choosing a plan is assuming live data is always better than delayed. In practice, plenty of teams pay hundreds of dollars a month for live data they use in places that never needed it — while others cut costs with a delayed plan and find that a core feature no longer works.
The right criterion is not "which tier is more advanced". It is how long your decision cycle actually is.
What "delayed" actually means
Delayed market data is not delivered the moment the market moves; it becomes available after an interval. Structurally it is identical to live data — same fields, same endpoints, same format. The only difference is timeliness.
That matters, because it means moving from delayed to live requires no structural code change, only a plan entitlement change. It also makes "develop on delayed, upgrade before launch" a genuinely viable strategy.
How to detect delayed data in code
Do not assume — check the field. Market data responses carry a delayed boolean that is true when the data is delayed:
import httpx
resp = httpx.get(
"https://api.tiqex.io/api/v1/market/quote",
params={"codes": "AAPL,EURUSD,BTCUSDT"}, # up to 50 codes per call
headers={"X-API-Key": "your_api_key"},
timeout=10,
)
body = resp.json()
for row in body["data"]:
flag = "delayed" if row.get("delayed") else "live"
if row.get("unavailable"):
flag = "unavailable"
print(f"{row['code']:<10} {flag} last={row.get('last')}")
Checking both delayed and unavailable prevents a familiar incident: you build against the free tier in development, ship to production, and discover some markets are actually delayed — with no validation anywhere in the code. Add a startup self-check that prints each market's live/delayed status, or assert that critical markets must be live.
Four situations where delayed data is entirely sufficient
- Historical analysis and visualisation. As long as the data is eventually consistent, latency does not change conclusions drawn from charts, reports, or trend analysis.
- Low-frequency strategies and rebalancing. A strategy that rebalances daily or weekly has a decision cycle measured in days; second-level latency is irrelevant.
- Portfolio valuation and risk snapshots. End-of-day valuation, position reconciliation, and exposure calculations work fine on delayed data.
- Development and testing. Integration work, unit tests, and CI validation are fully served by delayed data — and it is free.
Three situations that demand live data
- Trade execution and order decisions. Price is a direct input to the decision; latency means transacting at a stale price.
- Real-time alerting and risk control. Stop-loss notifications, volatility alerts, and risk threshold triggers lose their meaning when delayed.
- User-facing live interfaces. Trading terminals, market dashboards, research tools. Users can see prices moving, so delayed data produces an obvious experience gap and a trust problem.
What these three share: latency directly changes the decision outcome or the user's perception. If that is true, you need live data.
Mapping scenarios to plans
| Your scenario | Entitlement needed | Typical tier |
|---|---|---|
| API integration and prototyping | Delayed is fine | Free |
| Historical backfill and reporting | Delayed is fine | Free / Growth |
| Live monitoring for crypto and metals | Live (subset of markets) | Growth |
| Cross-market live dashboards (equities + FX + crypto) | All markets live | Pro |
| Level 2 depth and private connectivity | All-market Level 2 | Enterprise |
One thing worth noting: market entitlements are tiered, not all-or-nothing. A mid-tier plan may give you live crypto and metals while equities, FX, and indices remain delayed. So evaluate per market, not by plan name alone.
Hybrid approach: spend your live budget where it counts
If budget is limited but you do need live data, a hybrid pattern works well:
- Stream the critical symbols. Subscribe over WebSocket only for the few symbols that drive real-time decisions.
- Query the rest on a delay. Pull non-critical symbols periodically over REST.
- Label data freshness in the UI. Mark delayed values with a timestamp or indicator so users are not misled.
This controls cost and avoids the quota and throughput pressure of going fully live. Note that WebSocket subscription counts are bounded by your plan, so confirm that limit during evaluation.
How much latency your strategy can tolerate
A practical way to decide is to derive your latency budget from your decision cycle:
| Strategy horizon | Decision cadence | Latency that matters |
|---|---|---|
| High-frequency / market making | Sub-second | Single-digit milliseconds |
| Intraday trading | Seconds to minutes | Under one second |
| Daily rebalancing | Once per day | Minutes |
| Weekly / monthly allocation | Days to weeks | Hours |
Read this against your own cadence. If your fastest decision happens once a day, paying for millisecond data buys precision you will never use. If your fastest decision happens every second, delayed data makes the system wrong rather than merely slow.
An easily missed trap: cache semantics differ
Delayed data has a property that is easy to overlook: repeated requests within the same moment can return the same value. Cache logic written against delayed data breaks when you switch to live, because live requests can return a new value every time.
The typical symptom: caching for 60 seconds looks perfectly fine in development, then after switching to live, users report "the price isn't moving". Cache strategy must match data timeliness — delayed data tolerates long caching, while live data belongs on a push channel, not poll-and-cache.
FAQ
Does delayed data affect backtest results?
Yes, but how much depends on the strategy's horizon. For daily rebalancing, a few minutes of delay barely moves the result. For minute-level or faster strategies, delay changes the signal outright and the backtest is not trustworthy.
What can I do with free-tier data?
The free tier covers delayed crypto, US equities, and metals. That is enough for API integration, prototyping, historical backfill, and low-frequency analysis — its purpose is letting you validate the full workflow at zero cost.
How do I confirm whether a market is live or delayed on my plan?
Two ways: read the delayed field in the response, or check the plan's market entitlement documentation. Assert it in code for critical markets so you never discover it after launch.
Can I develop against delayed data and switch later?
Yes, and it is recommended. Delayed and live data share an identical structure, so switching is an entitlement change rather than a refactor. Just remember to revisit your caching strategy.
Where does Level 2 fit?
Level 2 provides deeper order book depth and is a higher entitlement, typically available only on the top tier. It is an independent axis from live versus delayed — Level 1 data can also be live.
Is delayed data cheaper because it is lower quality?
No. It comes from the same underlying feed; the difference is purely when it becomes available to you. Delayed tiers cost less because the data has less immediate commercial value, not because it is less accurate.
Next steps
Establish your decision cycle first, then verify entitlements per market. Market coverage and the live/delayed split across tiers are on the pricing page; per-market detail is on pages such as crypto and US stocks. The delayed and unavailable response fields are documented in the multi-market quote docs. If order book depth is part of the decision, start with Level 1 versus Level 2. Before committing to a tier, instrument your application to log the delayed flag for every market you touch — a week of real usage will show exactly which markets need live entitlements and which can stay on delay indefinitely.