June 1st, 2024
Last updated
Last updated
We made the Kraken integration available for all TradersPost customers. Please remember that this integration is in BETA and you may experience issues that we have not discovered yet. It is recommended to test with a paper account first. Read more about this integration in the Kraken Documentation. If you have any issues or questions, please email us at support@traderspost.io
We've added initial support for Alpaca Options in BETA. You can read more about Alpaca options here. If you have an existing Alpaca account connected to TradersPost, you will need to reconnect the account in order to enable options support. All new Alpaca accounts that get connected to TradersPost will have support for options.
All signal settings will be used by default and to ignore the signal settings, you will have to uncheck the Use signal settings checkbox. We decided that it was better to be enabled by default since most people will want to use the settings from the signal. If you are using a strategy with hardcoded JSON, you can uncheck Use signal settings and then configure your own settings in your strategy subscription. All existing strategy subscriptions will have Use signal settings disabled, but new strategies and subscriptions created after today will have it enabled by default.
You can now control the order type from webhooks with the new field named orderType. The orderType field is optional. If not specified, the default order type configured in your strategy subscription settings will be applied. The supported values for the orderType field are:
market
limit
stop_limit
stop
trailing_stop
A limit order allows you to specify the maximum price you are willing to pay when buying a stock, or the minimum price you are willing to accept when selling a stock. This ensures that you do not pay more or receive less than this specified price for the stock.
For example, to set up a limit order to buy the ticker symbol SQ at a maximum price of $200, you would use the following JSON structure:
A stop limit order combines the features of a stop order and a limit order. When you place a stop limit order, you specify two prices: the stopPrice and the limitPrice. The order will only be executed at the specified limit price or better, but only after the stock price reaches the stop price. This type of order gives you control over the price at which the order should be executed, helping to limit losses or protect profits.
For example, to place a stop limit order for the ticker symbol SQ to buy at a limit price of $200 only after the price rises to $201, you would use the following JSON structure:
In this example, the action is set to "buy," indicating a purchase. The orderType is stop_limit, specifying that this is a stop limit order. The stopPrice is set at $201, which is the price the stock must reach before your limit order is placed. Finally, the limitPrice is set at $200, indicating the maximum price you are willing to pay per share.
In this example, the orderType is trailing_stop, featuring a trailPercent of 2%. This configuration means that the order to sell the stock will activate when its price falls 2% below its peak value since the order's initiation. This mechanism allows investors to safeguard their gains by setting up an automatic sell trigger in response to price declines.
Instead of a percentage, you can specify a trailing stop order with a fixed dollar amount using the trailAmount field. This means the order will be executed once the asset's price moves against the direction of the trade by the specified dollar amount from its peak value since the order was placed.
In this example, buying MSFT stocks is triggered when their price decreases by $5 from the highest price since the order was placed. This method is particularly useful for stocks with higher volatility, as it allows for more precise control over the execution price.
Note that if you are using Tradovate, you must include a signalPrice in your JSON to be able to calculate the starting trailing stop price correctly for Tradovate.
With the introduction of the quantityType field in the webhook, you can now control the dynamic calculation methods for quantities previously only available from within your strategy subscription settings. Below are the allowed values for quantityType and examples for each.
The fixed quantity is the simplest quantity type. In this example it will simply buy 10 shares of AAPL.
In this example it will buy $10000 worth of AAPL. If the current price of AAPL Is $100, then it will calculate a quantity of 100.
In this example it will buy 10 shares because we've said that the most we want to be able to lose is $100. If we get filled at $180 and we have a stop loss at $170, then if we get stopped out we'll lose $10 per share, which means we can afford to buy 10 shares.
In this example, if you have a $100000 account and you want to buy AAPL using 10% of your total equity, and your limitPrice is $100, then it will calculate a quantity of 100 shares.
In this example, we are selling 50% of the open AAPL position. If the total quantity of the AAPL position was 100 shares, then it would calculate a quantity of 50.
You can now control the option chain scanning functionality from webhooks! In this example, it will buy SPY calls that expire in 6 months, are in the money and are 2 strikes away from at the money. It will calculate a quantity dynamically for $1000 worth of calls.
You can directly send a specific options contract symbol via the webhook, eliminating the need to scan the option chain to find a contract to trade.
To send a specific options contract through the webhook, include the contract symbol in the ticker field in your payload. This field should contain the full symbol of the option contract you wish to trade. Here's an example of how to structure your payload:
In this example, SPY 240510C516 represents the symbol for a specific SPY contract. The structure of this symbol is broken down as follows:
SPY is the underlying asset.
240510 indicates the expiration date, which is the 10th of May, 2024.
C signifies a Call option.
516 refers to the strike price of $516.
By specifying the contract symbol in this manner, you ensure that the exact desired options contract is selected for trading, bypassing the need to scan the option chain to find a contract dynamically. You can manually pick which contract you want to trade ahead of time and keep it up to date as contracts expire.
You can also optionally specify the specific contract to trade with individual field instead of using the symbol format in the ticker field.
In addition to being able to control more order attributes from webhooks, you can also control them from strategy subscriptions with the following new settings.
Entry order type
Entry time in force
Exit order type
Exit time in force
You will see these new settings in the Entry and Exit sections when editing a strategy subscription.
The option chain scanning feature now includes a snapshot of the option chain at the moment a trade was executed. This allows users to visually see the selected contract according to their configured settings. You will see this option chain snapshot when editing your strategy subscription and when you are viewing an individual subscription trade.
You can now send prices in webhooks for options trades. Previously, if you were to send a limitPrice for an options trade, it would be ignored and we would always fetch a quote and use the price from the quote for the limitPrice.
This feature is disabled for all existing options strategy subscriptions that predate this feature and is enabled for all new strategy subscriptions created after this change. You can enable and disable this feature in the Entry or Exit sections when editing your settings.
You can now control which quote price is used when calculating entry and exit orders. Prior to this change, it would always use the Bid-ask midpoint price. You can now control this explicitly for entries and exits under the Entry and Exit sections using the Entry market price type and Exit market price type dropdown. The allowed options are:
Bid-ask midpoint (default)
Use ask for buys and bid for sells
Always use ask
Always use bid
Use last price
We introduced a new webhook JSON field named signalPrice which can contain the current market price at the time the signal was generated. In the cases where we are not able to fetch a quote from the broker we will use the signalPrice in place of the quote. This addition is mainly relevant for Tradovate which does not support fetching quotes, so you always need to send a signalPrice with your signal to be able to perform relative price calculations.
Here is an example where we are executing a market buy order with a relative $5 trailing stop loss attached to the entry. To be able to calculate the initial stop price to send to Tradovate, we need a price to base our calculation off of. In this example we will use the signalPrice with a value of $100 and it will calculate an initial stop price of $95.
Tradovate now support trailing stops. Since Tradovate does not support fetching quotes, you will need to include a signalPrice in your webhook JSON so that we are able to calculate your orders correctly. In the below example, we will calculate the starting trailing stop price as $18350.
Or if you want to send a percentage instead of a fixed dollar amount, you can do that as well using the trailPercent field.
You can also send trailing stop orders along with your entry order as well. In the below example, the entry order will be a limit order with a limit price of $18250 and a trailing stop order with a starting trailing stop price of $18150.
Or with a percent instead of an amount.
You can now opt in to all signal settings with one checkbox named Use signal settings instead of having to opt in to each one individually. This setting is enabled by default too. So by default, signal settings will be used unless you turn it off.
When sending a webhook with a stop loss, use the trailAmount field to specify a relative trail dollar amount. This naming was updated from trailPrice to better reflect that it represents a relative dollar amount instead of an absolute price.
While we will continue to support trailPrice for backward compatibility, we recommend using trailAmount for future implementations.
