Confirmation on md/getChart parameters and volume

Looking at the example example-api-js/tutorial/WebSockets/EX-10-Chart-Data at main · tradovate/example-api-js · GitHub it’s not clear how to get the volume for a bar from the data returned, I assume it’s to sum the up and down volume’s, but is that correct ?

Also, when getting a chart via the market replay with the following description:

chartDescription: {
	underlyingType: 'MinuteBar', // Available values: Tick, DailyBar, MinuteBar, Custom, DOM
	elementSize: 1,
	elementSizeUnit: 'UnderlyingUnits', // Available values: Volume, Range, UnderlyingUnits, Renko, MomentumRange, PointAndFigure, OFARange
	withHistogram: false,
},
timeRange: {
	asMuchAsElements: 20,
},

The same timestamp will be emitted multiple times after the initial set of 20, I assume this is to get the progressive effect of the bar being built out in real time, and the final bar is the one prior to the timestamp moving to the next minute ?

Hi @Mikeb,

You’re assumption is correct, you add the bid volume to the offer volume to find total volume over a set. Regarding incoming chart data, yes the same timestamp being emitted again and again means you’re in a real-time bar. When the timestamp changes, you’ve moved to the next latest bar.

Market Replay will play back market history from the given timestamp forward as if it were happening live. You can adjust the speed parameter up to a value of 400 to make it play at up to 400% of its real time speed.

For chart timeRange parameters and knowing about the end-of-history flag:

  • The asMuchAsElements parameter will tell the server to emit n elements (or the rate limit on elements at the time of request if n is too big) up to the latest bar. Once it has loaded the elements up to the real time data, it will also emit an ‘end of history’ flag object. The only data contained in the EoH object is { id: 12345, eoh: true }. You can tailor your onmessage callback for the socket to watch for that flag to know when you’ve hit the latest bar.

  • If you want to request a specific set from the past you need to use the asCloseAsTimestamp and asFarAsTimestamp parameters. You can provide them as JSON encoded dates to get a specific range of history -asFarAsTimestamp being the oldest piece of data in the set, and asCloseAsTimestamp being the nearest. In this scenario the { id: 12345, eoh: true } flag indicates you’ve either hit the rate limit on bars from one request, or all the bars from the set you requested have been retrieved.

  • If you hit the rate limit going back in history, which is fairly common for large sets, you’ll need to md/cancelchart on the current subscription. You should send the body of md/cancelChart as { subscriptionId: <realtimeId of req> }. The realtimeId will come in the first response from md/getChart. Once you’ve unsubscribed, take the oldest piece of data in the set you’ve retrieved so far and start a new request with the oldest timestamp being the new asCloseAsTimestamp parameter in your request.

@Alexander thanks for the detail and answering those!

The one thing I noticed with historic data it’s not guaranteed to be in order. Just leaving that as a note for anyone else who reads this.