TBT 50-depth socket: update frequency, timestamp precision, unused proto fields, and access to true tick-by-tick data

Automate, API & MCP
1

I am about to buy the Prime plan but need following questions answered.

I use the Fyers API v3 TBT socket (wss://rtsocket-api.fyers.in/versova, mode depth) through the official Python SDK, fyers-apiv3 3.2.0 (FyersTbtSocket), following your documentation. I subscribe on one channel and resume it with switchChannel. I have measured the stream for NSE:NIFTY26OCTFUT, NSE:BANKNIFTY26NOVFUT and NIFTY ATM options, and would be grateful for clarification on a few points.

What I observed (session of 23 Oct 2026, 09:15–15:30 IST)

  1. About 2 packets per second per symbol. NSE:NIFTY26OCTFUT gave 23,634 packets in the session (1.05/s on average). Of the seconds with data, 11,097 had exactly 2 packets, 2,344 had 1, and none had more than 4.
  2. Whole-second timestamps. feed_time and send_time never carry a sub-second part.
  3. Each packet looks conflated. After applying the diffs, a median of 90–100 of the 100 price levels change between consecutive packets. That looks like all the changes over an interval in one packet, rather than one packet per order-book event.
  4. Many trades per packet. The same contract traded at least about 85,000 times in that session, by my estimate from the data socket’s volume and last-traded quantity. That is several trades per TBT packet, before counting order additions and cancellations.
  5. No packets are lost on my side. sequence_no steps by exactly 1 between consecutive packets.
  6. Snapshot timestamps. The snapshot packets sent on subscribe carry a feed_time of 1–3 seconds since the Unix epoch, not the current time.
  7. A fixed SDK bug that isn’t in the changelog. Up to version 3.1.18, the SDK placed diff levels by their position in the list instead of by num (the bug reported on your community forum on 25 Sep 2026). After I upgraded to 3.1.19+, the misordered rows we had seen (19–82% of rows) fell to zero. I could not find this fix in the changelog.

My questions:

  1. Your TBT overview describes tick-by-tick data as “recording every trade and order book update in real-time”. Is the TBT 50-depth stream conflated? If so, at what interval, and is that interval the same on the Prime plan?
  2. Is a finer exchange timestamp (milliseconds or better) available for TBT packets or for the data socket?
  3. MarketFeed in msg.proto also defines quote (ltp, ltt, ltq, vtt, vtt_diff, oi), ohlcv and dq. The documentation says these can be ignored, and the SDK reads only depth. Does the TBT server populate them? If it does, is vtt_diff the volume traded since the previous packet?
  4. Does Fyers offer, on any plan, add-on or through a partner, a true tick-by-tick feed? By that I mean every order add, modify and cancel and every trade print, with exchange timestamps. Is any historical depth or TBT data available?
  5. Is the regular data socket (SymbolUpdate, DepthUpdate) also conflated, and at what interval? I see about 1.4 and 1.0 updates per second for NIFTY futures. Does litemode affect this?
  6. Is a feed_time of 1–3 on subscribe snapshots expected? Should we use send_time for those packets?
  7. Could you confirm that the num-indexing fix is in 3.1.19 and later, and add it to the changelog?