Verify Order Placement
Verify a new order before placing it
Overview
This POST endpoint enables you to verify an order before placing it in AutoShares. This might be useful for ensuring that the user has properly constructed an order and prevent any issues related with defective orders.
There are five required parameters that must be provided in the request:
Authorization (header). This is the authorization token from the very first token request. The value of this header must have the following format:
Bearer BQ898r9fefi
(Bearer
+ 1 space + the token).API version (path). Unless necessary, leave it at "1.0".
Trading Account ID (path). This is the numeric ID of the trading account on which an existing order replacement must be verified.
placeParams (body). This is a JSON file that contains the parameters of a new order that must be verified.
Optionally, you may add another header that will return localized error messages in the required language:
language. Possible values:
en-US
,ja-JP
,ru-RU
,zh-CN
,zh-TW
. For example:'language': 'ja-JP'
Here's the final template for this API request:
For orders that will only be verified by the API but not the execution venue (quick):
For orders that will be verified by the API and the execution venue too (slow):
Request Body
The body of this request represents the information of the new order that must be verified before you can proceed to place it. The order must be sent in the JSON format with mandatory parameters about the order as follows:
Symbol
This is the ticker symbol of the underlying security in the new order.
ClientId
This is the order ID on the client's side.
ExpireDate
This is the expiration of the order. If the order isn't executed until the specified date, it'll automatically be cancelled.
Type
This is the type of the order. The range of possible values includes: Market, Limit, Stop, Stop Limit.
Side
This is the side of the trade. The range of possible values includes: Buy, Sell, SellShort, BuyToCover.
ExecInst
Indicates if the order should be filled either entirely in one transaction or not at all. Possible value: 'AllOrNone'.
TimeInforce
Indicates the time frame in which the order will be active. Possible Values:
Day. The order automatically expires at the end of the regular trading session if it weren't executed.
GoodTillCancel (Good-till-Canceled). The order persists indefinitely until it is executed or manually cancelled.
AtTheOpening. The order should be filled at the opening of the marketplace or cancelled.
ImmediateOrCancel. The order should be completely or partially filled immediately. If partially filled, the remaining part of the order should be cancelled.
FillOrKill. The order should be filled immediately and entirely or cancelled right away.
GoodTillCrossing. The order will be active until the market enters the auction phase.
GoodTillDate. The order will be active until the date specified in the ExpireDate attribute (unless it is executed or cancelled).
GoodTillTime. The order will be active until a certain time point.
Quantity
The number of shares in the order.
Price
The price at which the shares must be purchased.
StopPrice
When this price is reached, the order will automatically be converted into a market order.
Exchange
This is the exchange on which the order should be executed.
TrailingStopAmountType
This is the type of the trailing stop (Absolute or Persentage).
TrailingStopAmount
This is the trailing amount of the trailing stop (in percentage terms or in the currency units).
TrailingLimitAmountType
This is the type of the trailing limit (Absolute or Persentage).
TrailingLimitAmount
This is the trailing amount (in percentage terms or in the currency units).
ExtendedHours
Indicates if the order should be placed during the extended hours (pre-market session, post-market session).
ExecutionInstructions
Execution instructions for algorithmic trades.
Legs
These are the legs of a multi-leg order.
Smallest Market Order Verification Sample
Smallest Limit Order Verification Sample
Smallest Stop Order Verification Sample
Smallest Stop-Limit Order Verification Sample
Limit Order Verification Sample (Options)
Complex Order Verification Sample (Options)
Multi-Leg Order Verification Sample (Option + Option)
All legs of a multi-leg order should contain only three parameters:
Ticker symbol
Quantity
Side
All other parameters like the order's type and limit price must be specified outside the legs as the root parameters applicable to all legs.
The type of a multi-leg order must be either market or limit.
Comprehensive Limit Order Verification Sample
Comprehensive Market Order Verification Sample
Comprehensive Stop Order Verification Sample
Comprehensive Stop Limit Order Verification Sample
Comprehensive Trailing Stop Order Verification Type
Comprehensive Trailing Stop Limit Order Verification Type
One-Triggers-the-Other Order Verification Type
One-Triggers-the-Other is a type of conditional order in which execution of one order automatically triggers the other one. Each of the two orders has to be provided as a separate leg:
In this case, if the limit order to purchase the Apple stock gets executed, the second limit order to purchase the Tesla stock will automatically be triggered.
In One-Triggers-the-Other orders, the first leg cannot be a market order.
One-Cancels-the-Other Order Verification Type
One-Cancels-the-Other is a type of conditional order in which execution of one order automatically cancels the other one. Each of the two orders has to be provided as a separate leg:
In this case, if the limit order to purchase the Apple stock gets executed, the second limit order to purchase the Tesla stock will automatically be cancelled.
In One-Cancels-the-Other orders, both legs cannot be market orders.
One-Triggers-OCO Order Verification Type
One-Triggers-OCO is a type of conditional order in which execution of one order triggers execution of a One-Cancels-the-Other order. This order type is useful in strategies where you purchase a security (trigger) and then automatically configure a stop-loss and a take-profit order (OCO). The first order — the trigger — is provided as the first leg while the OCO order is provided as the second and the third legs.
Response
In response to this request, you'll receive a JSON file confirming (or rejecting) that the new order has been properly constructed.
where:
IsSuccessful
This field indicates if the order has been successfully constructed.
Commission
This is the total commission applicable to the order.
Commissions
This is an array that breaks down the applicable commissions.
Cost
This is the total cost of the order (including commission).
NetCost
This is the cost of the order less commission.
TotalCost
The gross commission applied to the order (includes all other commissions).
Quotes
This is the last batch of quotes for this security (includes the security's ticker symbol, its internal identifier in AutoShares, and the quote's timestamp).
MarginChange
This is the amount by which the trading account margin requirements will be affected once this order is filled.
ErrorDescription
This is the description of the error in case the provided order was improperly constructed.
ErrorDescriptionArgs
This is an array with error description arguments.
Common Mistakes
Here are some of the common mistakes that developers make when attempting to verify a new order.
Failing to Specify the Et-App-Key Parameter
If you specify the wrong Et-App-Key parameter or fail to include it in the header altogether, you'll get the following error:
Providing an Incorrect Set of Parameters
Another common mistake made when sending this API request is failing to provide all mandatory parameters. Doing so will result in the 500 status code and the following error message:
Placing Orders Whose Value Exceeds the Account's Buying Power
When attempting to verify an order whose value exceeds the trading account's buying power, you'll receive a JSON file with the ErrorDescription
parameter equaling DayTradingBuyingPowerExceeded
.
Failing to Specify the Limit Price for Limit Orders
An attempt to verify a limit order without specifying its price will result in an error; in response you'll receive a JSON file with the ErrorDescription
parameter equaling LimitPriceUndefined
.
Failing to Specify the Stop Price for Stop-Loss Orders
An attempt to verify a stop-loss order without specifying its price will result in an error; in response you'll receive a JSON file with the ErrorDescription
parameter equaling QuotePriceIsInvalid
.
Misformatting the Payload
If the payload is somehow misformatted, the following error will be returned:
The following article covers the syntax for this API request in detail.
Last updated