New Market Data Web-sockets Discussion

Hi folks!

We’re building a whole set of new web-sockets for streaming live market data.

Our key focus is to increase the number of instruments that can be subscribed at once and reduce any issues(lag, latency, etc) while the connection is set.

We’ve decided on a base structure and mode types that would help to solve for most users. But it would be great to know from the community as well. Also, any constructive feedback would help us get better.

You can register here and get a sneak peek into what’s happening and coming up!
Registration link: Upstox API - New Websockets · Luma

See you there! Cheers!

Hello Mohit,
Don’t know the current status.
Here my two cents, I think channel based subscription will be best
you can offer different functionalities into different channel that user can subscribe as per the need, here is an example of candlestick patterns

{
    "type": "subscribe",
    "payload": {
        "channels": [
            {
                "name": "candlestick_1m",
                "symbols": [
                    "SBIN",
                    "BHEL",
                      ..,
                      ..
                ]

                "name": "candlestick_5m",
                "symbols": [
                    "SBIN",
                    "BHEL",
                      ..,
                      ..
                ]

            },

In response it could be like below where you have type of channel and for candlesticks candlestart time and normal timestamp for tick by tick data, people can combine tick by tick data based on the type, resolution and candlestart time to separate and generate any aggregate candle. With this data is expected to be as accurate as possible i think and scalable as well.

{
    "candle_start_time": 1596015240000000,
    "close": 830,
    "high": 845,
    "low": 820,
    "open": 825,
    "resolution": "1m",
    "symbol": "SBIN",
    "timestamp": 1596015289339699,
    "type": "candlestick_1m",
    "volume": 12000
}

Hi,

I’m not sure if really the two OHLC data for 1min (I1) & 30min (I30) are useful and how anyone is using them (current & earlier duration data). Instead if we have one OHLC data each for 1min, 3min, 5min & 30min it will be great.

Also, it will be easy to work with data if each intervals are nested dictionaries rather than keys inside ohlc. for ex:

“marketOHLC”: {
“ohlc_1min”:
{
“open”: 260,
“high”: 282.7,
“low”: 136.75,
“close”: 141,
“volume”: 32205075,
“ts”: “1725820200000”,
“vol”: “32205075”
}