Anyway to get 1 tick bar data for more than a week?

API Developers
1

I am trying to find a way to programmatically backtest the strategies I’m working on and be able to run real-time tick data through the strategy to emulate the actual trades (including their size, time, etc). When requesting market data for a “1 tick size” chart, I only am able to get data for the last week it appears? If I change the asFarAsTimestamp or closestTimestamp parameters past this I just get a frame without anymore historic info with eoh: true.

Is this a hard limitation set forth by tradovate? Or is there a workaround to be able to collect individual ticks past the current limitation for the intended use to emulate actual trades through my strategies to get more of an accurate idea of how my algorithms will behave in real market conditions?

I understand there is a market replay feature but that would still bottleneck the time each strategy will take to test as we’re limited to the “speed” of the replay being 4x

2

You’re hitting the batch limit - it’s a flexible maximum data amount that limits how much data we send in a single batch. To work with this limitation, do the following:

  • Create a request that has closestTimestamp set to the latest date and an asFarAsTimestamp set to the earliest date that you want data for.
  • Wait for the { eoh: true } flag. This can mean two things, but in this case it means that the set has loaded either max batch size or the whole request and the data transmitted is done.
  • If you don’t have all your data yet, you need to look back again. Order the data you have so far by timestamp. Take the oldest timestamp you find and store it. This is the new closestTimestamp value.
  • re-run your original request with the new closestTimestamp value and the same asFarAsTimestamp value. After each batch is loaded, check to see if the batch made it to the asFarAsTimestamp date - if so, you’re done. Otherwise repeat the requests using the above method until you have arrived at your destination.

There is more information on this in the API FAQ repo.

Keep in mind, the advantage of the Market Replay is that it also has an engine to fully simulate trading in this scenario (so a complete fill engine that imitates live trading exactly as it would have occurred for a day).

3

Thanks for getting back on this Alexander!

The loop that I have running trying to accumulate all the single tick data takes the asFarAsTimestamp and closestTimestamp into account and still does not return data after about a week (from what I can tell) the 4096 bar limit that I think you’re talking about behaves as expected for all other charts and tick amounts (as far as I can tell) but the single tick request behaves differently in both the type of response (having to calculate the close, time, etc based on the base levels) and in regards to not returning data after a short period of time.

Is there any workaround with this specifically with a 1 tick request?

I really appreciate any help here as being able to accumulate this data would be huge for quickly backtesting different strategies as fast as possible!

4

To clarify: Once you hit the batch max (which for this request seems to be around 4096 elements) you need to cancel the current subscription and create a new one. The new subscription will be requested with a modified body. The new body will have the same asFarAsTimestamp and a modified closestTimestamp based on the oldest item that you received. You will use the { eoh: true } flag to determine when to cancel and resubscribe.

The one other thing you could do (in light of this being about ticks) is use the ID of the oldest tick instead of the timestamp. Then you could use closestTickId instead of closestTimestamp, which may be more suitable for ticks (as compared to time bars).

5

Here is a gif of the request flow I’m referring to using WebSocket Client to interact with the WS API

tradovate_1_tick

As you can hopefully see in the gif, I connect to wss://md-demo.tradovateapi.com/v1/websocket, send in the auth frame, then request a tick chart using this timeRange:

"timeRange":{"asFarAsTimestamp": "2022-04-01T19:29:00Z", "closestTimestamp": "2022-04-07T22:00:00Z"}}

I immediately get the eoh: true frame after receiving the historicalId frame

To prove that the request is valid for other ticks I make another request changing the request ID and the tick size from 1 to 2. I get the expected tick data back instead of immediately getting eoh: true

Does this make more sense as to what the issue I’m running into is?

6

Interesting tool, they ought to secure an SSL certificate. I see what you mean, though, that is strange. One thing I see is the md-demo tag. Try just wss://md.tradovateapi.com/v1/websocket and see if the behavior changes.

1 Like
7

It’s handy for doing stuff like this, wouldn’t use it for anything that needs to be transmitted securely. Since the token I’m using here is from the demo account I feel like it should be relatively safe to use for our purposes.

I tried using the recommended URL and received the same result. You can also see this happen in tradovate by trying to select 1 tick, the data is pretty limited.

From your reaction to this, it seems as though this is not intended? If that is the case is there any chance of having this functionality changed to what is expected here?

Again, I really appreciate your help on this!

8

Just to confirm, you took all the necessary steps to create an API Key etc? I can’t manage to reproduce this behavior. I get bars on multiple ticks, like you are showing, but on single ticks (for elementSize: 1) I’m getting arrays of objects that look something like this:

{
  id: 123456789,
  td: 0,
  ts: 0,
  s: 0,
  bp: 4670,
  bt: 123456789,
  tks: [ ... ]
}
9

Try dropping the time requirement for now and ask for timeRange: { asMuchAsElements: 200 } or something to that effect, just to see if maybe your timeframe is invalid.

10

I am able to get 1 tick data back in the format you listed above for about the last week of trading, once I try to go back further than the current week of trading it seems is when I get the condition above. As far as I can tell it’s not a timeRange issue as I demonstrated the same closestTimestamp and asFarAsTimestamp work for the 2 tick request as expected.

Can you see the message frame I used to demonstrate that in the gif above? That is how you can replicate the issue I’m having

11

Hey @Alexander I just wanted to touch base on this. Did you read my last post?