Discrepancy in Market Feed Data via WebSocket (v3 API) – Volume, OHLC Not Matching Charts

I’m currently using the Upstox v3 Market Feed Data API via WebSocket, and I’ve noticed a significant inconsistency between the data received through the WebSocket feed and what is displayed on the Upstox chart.

Specifically:

  • Volume traded data via WebSocket doesn’t match the chart volume.
  • Open, High, Low, Close (OHLC) values are also different when compared to the chart data for the same instrument and interval.

This discrepancy is causing challenges in maintaining data accuracy on my application. I’ve verified that I’m subscribed correctly to the tokens and receiving live ticks, but the mismatch persists.

Could someone from the team or community shed light on why this might be happening? Is there a known issue, delay in aggregation, or a different source used for chart rendering vs WebSocket?

Any help or guidance on how to resolve this or align the data sources would be greatly appreciated.

Thanks in advance!

Can you share some more info on your setup. First are you aggregating tickdata from websocket and storing it in a db?

Thanks for your response.

Yes, I’m aggregating the tick data received via the Upstox v3 Market Feed WebSocket and storing it in a database for analysis and charting purposes.

Here’s a brief of my setup:

  • I’m subscribed to the full market feed for selected instruments like HDFCBANK using the full mode (which includes OHLC, LTQ, volume, etc.).

  • On receiving each tick, I store the following:

    • Timestamp
    • Last Traded Price (LTP)
    • Last Traded Quantity (LTQ)
    • **Volume Traded (Total)
  • I aggregate these values at a **per-second or per-minute level to generate candles and compare them with the TradingView/Upstox chart data.

What I’m noticing:

  • Even though I’m receiving ticks continuously, the sum of LTQs within a second (or the delta in Volume Traded) is significantly lower than what the chart shows for the same timestamp.
  • For example, on 27-06-25 at 15:00:00, the Upstox chart shows 24.375K volume, but in my feed at that second, I only received two ticks — one with LTQ 108, one with LTQ 13.

This leads me to suspect either:

  1. The WebSocket feed is sending only snapshot ticks (not all trades), or
  2. There’s some filtering or throttling on the backend for equity symbols.

I would appreciate if you could clarify:

  • Whether the feed is tick-by-tick for all trades, or only the last trade snapshot within a time window,
  • And whether chart data is based on a different feed (such as Tick-by-Tick / co-location) that is not exposed via the public WebSocket.

Thanks again for your time and support.

Warm regards,
Madhukumar

@Pradeep_Jaiswar @MohitGolecha
Can we get a reply to this one, please?

Hi @Madhukumar_19862135 @Amit_Kumar_Sharma

The LTPC feed is not tick-by-tick. It needs over 100mbps of stable bandwidth to support a handful instruments. The OHLC is with TBT accuracy, 1min granularity and onwards. That 1 min candle stats will always match the Charts data. Its the same socket we’re using!

I too have observed the data discrepancy in live feed. I’ve subscribed in full mode and the data doesn’t match with the chart. PSB an example:

  1. I highlighted 10s slice of ticks as received, and I don’t see OHLC and Volume matching the chart.
  2. I also see that couple of ticks (upto 5s) the greeks & iv not getting updated.

But the chart representation as displayed by Upstox & Zerodha matches fine (of course in 1m slots)

Hello Team,
Any update on this data discrepancy. I have another instance where the tick wise reception is going wrong.
Look at the image below, The instrument in the example is SENSEX_81600_CE_20250911, the uts column is the "currentTs" coming as part of the feed, a.k.a upstoxTimeStamp, looking at carefully, if there are 2 trades in a sec, ideally the expected output is that the tick data carried in the socket should be in the ltt order. The actual output that I’m seeing is that the ltt order getting jumbled up.

Example:

  • at time currentTs:1757562303398, should have received ltt:1757562303253, but received ltt:1757562303482. Similarly, forward time currentTs:1757562303545 cannot carry old ltt.

Can you guys take a look at your end on priority? The time slot calculations are going wrong because of this. OR is that currentTs understanding is wrong? In theory, it cannot be right, i.e., currentTs is moving time window that shall be in sync with ltt, we should not be receiving previous ltt in forward time.

Thanks.

I’m observing the issue constantly, particularly on Sensex options instrument. Here is another example:

Instrument: 81400 CE
Trade Date: 12-Sep-2025
Expiry: 18-Sep-2025

utscurrentTs of the payload (i’m calling as upstoxTimeStamp)

Also illustrating what could be the potential problem (current behaviour in above pic):
CTcurrentTs, LTlastTradedTime

CT1 is carrying LT2 tick and CT2 carrying LT1 tick, which seems problem.

The expected result should have been as shown in expected behaviour in the above pic.

FYI: @Amit_Kumar_Sharma , @MohitGolecha