Live market data APIs in India: REST, WebSocket and what to ask a vendor

Search for a stock market API in India and you will find dozens of offers that look identical: live prices, a JSON response, a monthly price. Underneath, they are built very differently — and the difference shows up the first time your strategy trades on a number the exchange never printed.

Three products that share one name

A market data API is really three services, each with a different job. Confusing them is the most common reason a first build disappoints.

A good vendor gives you all three from the same recorded archive, so the bar your backtest saw is the bar your live system sees. That consistency is what Pix APIs are built around: realtime and historical data, Greeks, news and corporate data behind one set of credentials.

Tick versus snapshot: the difference you cannot see

Many low-cost feeds are snapshots: they sample the market at intervals and send you the latest state. It looks live. But every trade that happens between two samples never reaches you.

For end-of-day screening this rarely matters. For anything intraday — order flow, footprint charts, VWAP, scalping — it is the difference between a working model and a fiction. We explain the mechanics in what tick-by-tick market data actually means.

Licensing: the question most builders skip

Exchanges license their real-time data. A vendor who passes that data to you needs an agreement to do it, and the licence defines what you may do with it: display it, compute on it, or redistribute it to your own users. An unlicensed source can vanish overnight, or leave your product exposed. Ask for the vendor’s authorisation plainly; a legitimate one will answer plainly. The hidden cost of free data is usually paid here.

Ten questions to ask any API vendor

1. Are you an authorised vendor for these exchanges? And for which segments.
2. Tick-by-tick or snapshot? Ask for a sample and count the trades.
3. How far back does history go at tick, one-minute and daily resolution?
4. Is history adjusted for splits and bonuses at every resolution? See how corporate actions break charts.
5. What happens when my connection drops? Is the gap backfilled automatically?
6. What are the rate limits per second, per minute and per symbol?
7. Is there a maintained symbol master with expiries and lot sizes?
8. Are option Greeks computed and stored, live and historical?
9. Do live and historical come from the same archive? If not, backtests will not match live trading.
10. Who answers when it breaks at 9:14 AM? A named support route beats a ticket queue.

A minimal live architecture that holds up

Whatever you build, the shape that survives production is the same: a WebSocket client that only receives, a queue that absorbs bursts, a store that records every tick, and your logic reading from the store rather than the socket. Keeping them separate means a slow strategy never drops data, and a restart never loses history.

# the shape, not a full client
stream  -> receive ticks, never block
queue   -> absorb opening-bell bursts
store   -> append every tick with exchange timestamp
logic   -> read from store, act, log decisions

If you would rather have that built for you, our engineering arm builds trading applications and integrations on top of the same feed.

REST or WebSocket? A decision guide by use case

Five integration mistakes we see every month

• Subscribing to everything at the open. Hundreds of symbols requested in the same second hit rate limits. Stagger subscriptions over a few seconds.
• Doing work inside the message handler. A slow calculation blocks the socket and ticks queue up or drop. Receive fast, process elsewhere.
• Trusting the local clock. Use the exchange timestamp in each tick; your server clock drifts.
• Hard-coding the symbol list. Contracts expire and lot sizes change. Refresh the symbol master every morning.
• No reconnection test. Pull the network cable during market hours once, on purpose, before your users do it for you.

Questions traders ask