API clients interacting with TWS Build 983+, with the flag/checkbox "Use Account Groups with Allocation Methods" enabled, will see the following changes:
Beginning with release 9.72.18, a single data request from the API can receive aggregate quotes from multiple exchanges. With API versions 9.72.18 and TWS 9.62 and higher, the tick types 'bidExch' (tick type 32), 'askExch' (tick type 33), 'lastExch' (tick type 84) are used to identify the source of a quote. To preserve bandwidth, the data returned to these tick types consists of a sequence of capital letters rather than a long list of exchange names for every returned exchange name field. To find the full exchange name corresponding to a single letter code returned in tick types 32, 33, or 84, and API function IBApi::EClient::reqSmartComponents is available.
Different IB contracts have a different exchange map containing the set of exchanges on which they trade. Each exchange map has a different code, such as "a6" or "a9". This exchange mapping code is returned to IBApi::EWrapper::tickReqParams immediately after a market data request is made by a user with market data subscriptions. To find a particular map of single letter codes to full exchange names, the function reqSmartComponents is invoked with the exchange mapping code returned to tickReqParams.
For instance, a market data request for the IBKR US contract may return the exchange mapping identifier "a6" to tickReqParams. Invoking the function reqSmartComponents with the symbol "a9" will reveal the list of exchanges offering market data for the IBKR US contract, and their single letter codes. The code for "ARCA" may be "P". In that case if "P" is returned to the exchange tick types, that would indicate the quote was provided by ARCA.
For samples and more information, see http://interactivebrokers.github.io/tws-api/ smart_components.html
Soft Dollar tiers are supported in version 9.72.18, and require TWS version 959 or above.
Effective with TWS build 956, we have added the reqSecDefOptParams function on the EClient class to obtain the available Futures and Futures Options contracts for an underlying.
The function's parameters include:
The delivered information will be returned via the EWrapper's securityDefinitionOptionalParameter as:
Once all the information has been delivered, the EWrapper's securityDefinitionOptionalParameterEnd marker will be triggered.
Adjustable Stops, Pegged-to-Benchmark and Conditional orders are now supported in the API.
Adjustable Stops: Attach one-time adjustments to stop, stop limit, trailing stop and trailing stop limit order using the following new attributes within the Order class:
Pegged-to-Benchmark: Peg your order to a reference contract's movement in the market using the following new attributes within the Order class.
For examples go to: http://interactivebrokers.github.io/tws-api/basic_orders.html#pegged_benchmark
Conditional: Specify conditions that must be met before the order will trigger. Uses the following classes and new attributes within each class:
PriceCondition (new class)
ExecutionCondition (new class)
MarginCondition (new class)
PercentageChangeCondition (new class)
TimeCondition (new class)
VolumeCondition (new class)
For examples go to: http://interactivebrokers.github.io/tws-api/order_conditions.html
EClient Class: Positions and account updates can now be requested for a given account or model via reqPositionsMulti and reqAccountUpdatesMulti methods.
EWrapper Interface: Information is delivered via the new positionMulti/positionMultiEnd and accountUpdateMulti/accountUpdateMultiEnd callbacks.
Within TWS, we use the last trading day and not the actual expiration date for futures, options and futures options contracts. To more accurately reflect this data, we have changed all of the "expiry" fields throughout the API to either "LastTradingDay" or "LastTradingDayorContractMonth" as noted below.
For TWS messages being sent to the API client, the values is always Last Trading Day, and so the "Expiry" field has been changed to "LastTradingDay":
OPEN_ORDER = 5;
PORTFOLIO_VALUE = 7;
CONTRACT_DATA = 10;
EXECUTION_DATA = 11;
SCANNER_DATA = 20;
TICK_EFP = 47;
POSITION = 61;
For messages sent from the API to TWS, if the value length is 8, TWS understand it as the Last Trading Day. If the value length is 6, TWS understand it as the Contract Month. For these, the "Expiry" field has been renamed to "LastTradingDayorContractMonth":
REQ_MKT_DATA = 1;
PLACE_ORDER = 3;
REQ_CONTRACT_DATA = 9;
REQ_MKT_DEPTH = 10;
REQ_HISTORICAL_DATA = 20;
EXERCISE_OPTIONS = 21;
REQ_REAL_TIME_BARS = 50;
REQ_CALC_IMPLIED_VOLAT = 54;
REQ_CALC_OPTION_PRICE = 55;
For the above, the expiry field is wrapped in the Contract class. We have renamed Contract.expiry to Contract.lastTradingDayOrContractMonth.
The TWS API library can now communicate with servers when used as a mobile API over a secured SSL protocol. In conjunction with this added support, the EClientSocket, which was previously a combination of client functionality plus socket functionality/transport, was split to isolate socket functionality/transport in an ESocket class implementing an ETransport interface. This refactoring allows us to implement alternative transports, specifically SSL.
Two new attributes are supported for Volatility and Pegged to Volatility orders. These are available in all API platforms
Effective in TWS 950 and above, API users have the option to set the API to Read-Only mode. This mode allows viewing of market data and account information, but blocks any type of trading activity Additionally, users can elect to limit access only to connections made from the same computer. To set API parameters, from within TWS Global Configuration select API.
Beginning with this release, we have made the following changes to our API clients and sample applications:
We have added the following new connection features:
We have added a new Order attribute, Solicited to the Order object. Solicited is a boolean attribute with the following values:
The following new error codes have been added to the Java client:
Beginning with this release, we have made the following changes to the primaryExchange field:
We have fixed a bug with API orders that sent an end marker prematurely. Beginning with TWS beta release 948, the end marker will be sent to the API only after all of the orders have been delivered to TWS.