Submit a buy/sell order with a trailing stop loss

I am trying to have buy a future with a trailing stop loss only. I am having a hard time with getting the order parameters correct.

  1. Do I send the order to order/placeorder or orderStrategy/startOrderStrategy endpoint

can someone write a sample

You could use order/placeOSO. It is shaped like a normal order, except it has optional bracket1 and bracket2 parameters. You use the normal fields to define the entry order (like action, price, or stopPrice). In this scenario, just use bracket1 and ignore the bracket2 optional field. For the bracket1 parameter, make sure you use orderType: 'TrailingStop' and include a stopPrice. Here’s the docs.

What this should do is place your entry order, then when that fills it will send the trailing stop defined by bracket1.

The trailing stop portion of the order is not working. The order fills and then that’s it.



There is not order/placeoso order endpoint,
The buy limit order fills, the trailing stop order does not…

Following the order/placeoso order sample, i create this request.



Only the buy limit order is filled, the bracket1 order isn’t even registered.

I copied the code from the oso example and only the first Buy order is filled, the stop limit order never gets routed.



 -- got response message --
{'s': 200, 'i': 0, 'd': {'orderId': 3378049407}}

Is my message structure incorrect? Can you please assist with this…?

Okay, the issue is I do not need an oco or oso order. I just need a regular stopLoss, example:



That will Buy to close a short position at stop price.

I get an marketdata message when the trailing stop order is activated, but there’s no order when the trailing stop is filled. I hear the audible stop filled but I do not get any messages from the api or marketdata endpoints.

Can I register a listener for that message?

I am only getting the order notification for stop order filled, the trailing stop order doesn’t send any notification but the program will say stop filled.

Is it possible to get the stop filled notification from the md or api websocket connection?

even using the order/item endpoint, I have no way to validate if the trailing stop was touched or not.


api_websocket_run -- API -- got response message --
{'s': 200, 'i': 3, 'd': {'id': 3380645293, 'accountId': 000, 'contractId': 2396936, 'timestamp': '2022-02-22T09:53:23.339Z', 'action': 'Buy', 'ordStatus': 'Filled', 'executionProviderId': 1, 'archived': False, 'external': False, 'admin': False}}

Is there no way to get feedback on the trailing stop being filled?

There are a few routes to do this by. You can use these endpoints:


(replace orderId with your order’s id field)

This will give you all the command an execution data related to the order- so when you made the command to create the order, when you passed the risk check, when your order was filled, if it was canceled, rejected, etc. There’s a lot of information in command and execution reports that can help us understand what happened with an order and why.

You could also hook up a websocket and listen for entity creation/update events related to your order. This will end up giving you the same data - execution reports and command reports - you’d just be gathering it in real time (‘reactively’) instead of on a client-driven instantaneous basis via HTTPS.

I was having some issues with the executionReport endpoint earlier.

I am already using two websockets; the marketdata and api endpoints simultaneously.

I have marketdata socket connection receiving the market md events, then based on that information I make order decisions.

Can you elaborate on this, is this a marketdata or api endpoint? Where’s this documented?

To watch for user data events, connect to the realtime data api (wss://, do your auth procedure, then start a subscription to realtime data using user/syncrequest endpoint.

mySocket.send(`user/syncrequest\n1\n\n${JSON.stringify({users: [userId] })}`)

Once that is set up, messages will begin coming to the socket. Initially you’ll get a huge response object that will contain all of your persistent user data. After you receive the initial message, you’ll receive smaller update messages. Watch for messages that look like this:

  e: 'props', 
  d: { 
    entityType: 'executionReport' | 'commandReport' | ..., 
    eventType: 'Created' | 'Updated', 
    entity: [Object]

The message’s e field is the event type. This is always 'props' for user updates. The d field will contain some info about the entity event. entityType could be any of the types of entities stored by Tradovate. There are a lot of them, but most of them are listed in the user/syncrequest response object. From here you can check out the different entity types and their object shapes.

There’s some additional information about watching for this data in this section of the docs.

1 Like

Thanks, I did see the usersync request I overlooked it.

The initial object is very large, it’s casuing me to get a message too big error. I tried adding the splitResponses flag but i am still getting too large error. I also tried to add the userid as well but the message is still too large.

Is there a way to get smaller chunks of data? I've done quite a bit of simulated trading today and that could be causing issues.
The above error is a configuration specific. I sorted this part out… Turned off the max_size limit on the websocket connection.

This might be a bit out of the scope but I’ll ask; When I am getting the syncrequest messages, sometimes they are multiple messages concatenated together:

The above message has 2 props, is this just some of the issues i’ll have to solve dealing with the unprocessed market data?

The general rule with the API is expect messages to come in multiples. This is something that you’ll have to code to account for when you’re writing your message decoding procedure. The API’s WebSocket response data already arrives in arrays for a frames. This means that you can iterate over the responses in all cases to process the messages one at a time.

I wanted to come back and clarify. When I subscribe to the user/syncrequest endpoint. Sometimes you’ll get data that’s chunked together but not aligned to json objects, such as this:

This is true but the other data is sent in organized arrays. The issue I was facing was getting event data like the ones below.


trying to parse that as valid json will fail. I was able to use a regex below


that will properly split the above chunked stream of data into the correct Tradovate event messages.

Then iterate through the list of events and process as normal. Hopefully if anyone else runs across similar behavior in the future this thread can help.

Thank you @Alexander