Bid-Ask Volume

API Developers
2

You can use Realtime Market Data to stream these values to you live. You need to do a few things to open the socket:

  1. Ensure you have API Access and a subscription to realtime market data.

  2. Find a solution for your environment. If you’re programming using JavaScript in a browser, the WebSocket class constructor is a built-in. If you’re using Node.js, use node’s ws package to mimic the standard WebSocket api. If you’re using another language you’ll have to do some research, but as far as I know most languages have an implementation of websockets (if they’ve ever been used on the web anyway). Don’t forget to reference our WebSockets docs here for more details about our websockets API.

  3. Connect a websocket to the Tradovate Market Data API. Typical socket implementations will connect upon construction:

const mySocket = new WebSocket('wss://md.tradovateapi.com/v1/websocket')
  1. Authorize the socket. You do this by using an accessToken that you’ve retrieved using the standard Tradovate REST API.
//imaginary way to get accessToken, not implemented here
const { accessToken } = await myAccessTokenRequestFn(credentials) 
//construct the message. We use newlines as param delimiters
const authMessage= `authorize\n1\n\n${accessToken}`
//send the message to the server.
mySocket.send(authMessage) //=> [{i:1, s:200}] if successful
  1. Implement heartbeats. This is a whole topic in itself, but the idea is send a heartbeat to the server roughly every 2.5s to keep the connection alive. Don’t respond to server heartbeats directly, as when the server is transmitting data it will not emit heartbeats (but you’re still responsible for sending them). Just measure the time since the last message was received and send a heartbeat in the case that it’s been 2.5s or greater. A client side heartbeat looks like this:
mySocket.send('[]')
  1. Now you have a connection that will live for the length of your token’s lifetime. You can retrieve bid and ask data from md/getChart which is detailed here. Look at the bidVolume and offerVolume fields of each incoming chart data bar object. Alternatively, you can use md/subscribeDom to get more details about the bid/ask on a per-price basis. You can learn more about the DOM approach here.

Additional notes:

  • Keep in mind, data is ordered by timestamp. For charts, incoming data with the same timestamp came from the same bar. If you receive data with the same timestamp be sure to replace the previous data that had that timestamp. When data is coming to you live, it comes as a snapshot of what has happened so far - it is pre-aggregated. Therefore you don’t need to aggregate the incoming data, just replace the latest data until you receive a packet with a new timestamp. When this happens, you know you’ve moved into a new candle/bar.

  • Also for chart data, watch for the { eoh: true } end-of-history flag object. In the scenario you’re looking up historical data, this means you’ve either hit the limit of transmitted data, or you’ve reached the end of your request’s timeframe. If you’re requesting asMuchAsElements: n in your timeRange, the eoh flag represents that you’ve retrieved n || max packets of data. For this request type it also signals the start of realtime data.