Keyboard Shortcuts
Likes
- Twsapi
- Messages
Search
|
Re: new IBKR desktop APP
¿ªÔÆÌåÓýIBKR Desktop does not act as an API server, so it is by default out of the scope of this "TWS API" group I would think.
But I have looked at IBKR Desktop and it is in my opinion not for the serious investor or trader (which is traditionally the IBKR client base). It seems IBKR's attempt to have a more 'user-friendly modern looking' desktop client to better compete with retail brokerages (Robin Hood, TastyTrade etc) but a lot of functionality that is present in TWS is lacking.? For instance there is no Portfolio Risk tool as in TWS (an absolute must in my opinion if you trade anything short) and no ability to do What-ifs to evaluate eg impact on margin for new positions. The fact that IBKR Desktop also does not support Advisor-type accounts at this time is also an inkling it is not targeted to any 'professional' user. ? My opinion is that IBKR should have focused on bringing TWS in a modern UI (there are quite a few UI quirks in TWS) and introduce a Beginner mode to make it easier to use for novices, rather than starting from scratch the development of a new desktop client. They now have TWS, IOS-Mobile app, IBKR Desktop and their website that all look and feel different.? rgds, Bart On Sep 13, 2024 at 2:20?PM -0700, rwk via groups.io <rwk0434@...>, wrote:
|
|
Re: Submitting many orders simultaneously
According to TWS API documentation,
?
I have not placed orders at this pace and I'm not sure if any more fine-grained pacing is implied from the above mentioned limitations (like not more than 1 order per 1/50th of a second). My C# app typically places about 15 orders in a timeframe of 1-3 seconds daily and I envision it will place about double that amount soon, but it computes orders on the go from incoming price and execution data which dictates exogenous pacing and makes benchmarking of "pure" order placement throughput unfeasible. So maybe others will share their experience in this regard. I'm sure if your code is streamlined and snappy enough (including managing your own order ids instead of wasting message bandwidth on respective requests from TWS), there should be no problem placing a hundred orders in just a few seconds.
?
--
Best, DS |
|
Re: new IBKR desktop APP
I am a long time member of this group, but I have been away from it for awhile. Now I am re-evaluating my trading to better match my current interests and circumstances.
?
I have been working with the IBKR Desktop app, and I am wondering if anybody here is using or looking at it. I am thinking that multiple brains are better than one for working on this. If you're interested in wonky discussions, please speak up or contact me off-list at rwk0434[dot]com.
?
Thanks,
[Rich] |
|
Submitting many orders simultaneously
Hi. I am new here, so I apologize if this question has been covered already. Until recently I was trading on IBKR using the Client Portal API. Each day I would simultaneously place about 100 limit orders for various U.S. stocks, and I did this using the /orders REST endpoint. If one uses an array of orders as the payload of the post request, the orders are all submitted simultaneously. Sadly, on Sept 4 IBKR stopped allowed one to submit multiple orders this way. Only single orders are allowed now. But if I try to submit ~100 orders sequentially, it will take too long. I need to submit them all within a few seconds of each other. So, I am considering using the TWS API for this. My questions are:
Thanks very much for any guidance that anyone can give me. |
|
Re: API data not the same as TWS data?
You are probably looking for the list of available tick types that you can find at There you will see that BID, BID_SIZE, ASK, and ASK_SIZE are not related to trades but to, well, the current Bid/Ask prices and sizes. Trades are reported through the LAST and LAST_SIZE ticks. You should not see any differences between prices in TWS and data feeds you receive from TWS as long as you compare the same data sources (such as real time data feeds from reqMktData, reqTickByTickData, reqRealTimeBars, and reqMktDepth or historical data). Due to their different nature and purposes, prices from different feeds can be different. ´³¨¹°ù²µ±ð²Ô ? ? ?
?
On Fri, Sep 13, 2024 at 07:20 AM, Lalo F. wrote:
|
|
Re: How are built the Continuous future data retrieved with secType = CONTFUT ?
I seriously hope what you really wanted to say is "So the question is still opened, waiting for the answer from IBKR support." Otherwise it would sound like you feel entitled to an immediate answer from our group when IBKR has not responded in two months.. The welcome message you received when you signed up (and our home page at /g/twsapi) asks you to "Tell us what you have already tried, what worked, and what did not". Now you told us that you asked IBKR a couple of month ago, but what else have you done, and what did you find? You can get a pretty precise answer for your question within a few minutes yourself:
I assume you are looking for Historical Bar Data from reqHistoricalData. In that case, check whether the results are different when you request TRADES or ADJUSTED_LAST data. Let us know what you find. I would hope (but don't know) that reqHistoricalData(TRADES) is a simple concatenation of unmodified data. ´³¨¹°ù²µ±ð²Ô
?
?
On Fri, Sep 13, 2024 at 10:20 AM, <luca.chiaravalloti@...> wrote:
|
|
API data not the same as TWS data?
Hi there. I'm retrieving data from stocks using a Python script and the methods?tickPrice, tickSize and updateMktDepthL2
?
It looks like it is working, but checking the data I get from the API is not?similar at all to the data shown in TWS (or other apps). I'm wondering if I'm doing things right. I have been?reading about this on the internet and it happens to be a common?subject. I know I should count with some deviation, the bars I could build with fetched?data are not going to be exactly?the same as the TWS bars, but the samples I have checked are far away from being close.?
?
I'm trying to build?a system that takes data from the order book and trades (prices) to make a study, but with the provided?accuracy is impossible. I don't need a 100% accuracy, let's say a 98% will be fine.?
?
By the way, I haven't found any documentation about the retrieved data, is there someone who can give me a link or confirm my understanding is right:
?
05/09/2024 15:29:59.427 HBAN tickPrice reqId: 3 tickType: BID price: 14.85 attrib: CanAutoExecute: 1 PastLimit: 0 PreOpen: 0
05/09/2024 15:29:59.427 HBAN tickSize reqId: 3 tickType: BID_SIZE size: 2300 ?
The first line means an order has been filled in the BID side at 14.85? ?
The second line means the order had a size of 2300
So the last crossed price will be 14.85?
The same is true for ASK side orders.
?
05/09/2024 15:30:00.275 HBAN tickPrice reqId: 3 tickType: LAST price: 14.85 attrib: CanAutoExecute: 0 PastLimit: 0 PreOpen: 0
05/09/2024 15:30:00.276 HBAN tickSize reqId: 3 tickType: LAST_SIZE size: 2300? ?
This is much more tricky, it could be: 1) a confirmation of the previous trade, so they are always redundant, 2) Market orders crossed with other market orders
Could anyone confirm?
?
Thank you,
|
|
Re: How are built the Continuous future data retrieved with secType = CONTFUT ?
To create a continuous future, you must apply the back adjustment method with the various futures contracts that you downloaded.
The most recent future is used to calculate a coefficient that is used to adjust (going back) the closest expired future, etc. Here is an explanation: ?
[Edited by Moderator: this link shows one way to calculate continuous future data: it may not be the way IBKR does it.] |
|
Re: What is manualOrderCancelTime param of Eclient::cancelOrder( int id, String manualOrderCancelTime)
For the benefit of those members that do use Python with the TWS API (and ´³¨¹°ù²µ±ð²Ô surely with over 6,000 members I cannot be the only one, and therefore this has relevance to those members), I used the following method which works nicely.
?
# create the OrderCancel object
order_cancel = OrderCancel()
?
# add an empty string for manualOrderCancelTime to the object
order_cancel.manualOrderCancelTime = ""
# pass the object as the second parameter
self.cancelOrder(orderId, order_cancel)
?
Also DS, to clarify, I did indeed use square brackets as a symbolic notation of passing a single integer value as the OrderID, rather than this being the syntax of the code that would represent a list in Python.
?
As this was the last issue in my 6000+ line program that I so naively developed using a copy-and-paste approach, I am most pleased that the program now works perfectly and is rendering excellent daily results.?
?
Thank you all for your input.
|
|
How are built the Continuous future data retrieved with secType = CONTFUT ?
I submit the question to IB assistance 2 months ago, but no answer received until today.
So I ask the group:
As wrote in the subject:
How are built the Continuous future data retrieved with secType = CONTFUT ? The data are a simple concatenation of the data from the different contracts?
Or are the data from previous contracts rescaled avoiding gaps? How is the rollover date chosen? By volume change or expiry date or anything else? I did not find any info about on the web. Anyone know the method used by IB to build the Continuous version of futures?
|
|
Re: Expired contract & TimeZoneId
I asked IB assistance, their answer was so:
-------------
Now, when using `reqContractDetails()` to get the contract details of expired Future contracts, the timeZoneIds are always Null.
This is by design. However, there is always a timeZoneId get returned when you `reqContractDetails()` to get the unexpired Future Contracts.
For example, the `ES FUT USD CME 20240920` returns the timeZoneId: US/Central. Unexpired Future Contract timeZoneId is always same as the expired Future Contract timeZoneId.
You can get the unexpired Future Contract timeZoneId to know the expired Future Contract timeZoneId.
-------------
Let me notice that it is not a very good design idea, a field "isExpired" should be present instead!
?
|
|
Re: Rolling futures to the next expiry
I have been looking into calendar spreads for a few weeks and it looks to me that what you experience is intended this way. By default and documented as such in the tool tips, TWS seems to
If you BUY 1 spread of RTYU4-Z4 you will get positions: -1 RTYU4 and +1 RTYZ4 If you SELL 1 spread of RTYU4-Z4 you will get positions: +1 RTYU4 and -1 RTYZ4 With the "Spread Trader" in TWS or via the API you can define this the other way around, but I got myself turned around a few time when buying and selling the various combinations. So I decided to stay with that "front -1, back +1" convention for my TWS API implementation calendar spread order placement. ´³¨¹°ù²µ±ð²Ô ?
On Mon, Jun 24, 2024 at 03:52 AM, Brian wrote:
|
|
Re: What is manualOrderCancelTime param of Eclient::cancelOrder( int id, String manualOrderCancelTime)
In client API 10.19 the method's signature suggests an object of type OrderId for the first operand, which appears to be equivalent to a single int, i.e. a primitive integer type. Since square brackets indicate a list of objects in Python, it goes against the signature, and although typing annotations in Python are purely suggestive, in fact the source of the method itself indicates this shouldn't really work.
?
I frankly didn't pay much attention to this artefact assuming it could be some type of symbolic notation but if it's a direct quote then it definitely doesn't look right to me unless newer API versions introduce changes to the method allowing to pass it a list of order ids.
?
--
Best, DS |
|
Re: What is manualOrderCancelTime param of Eclient::cancelOrder( int id, String manualOrderCancelTime)
Just to wrap this up (since we are moving from an TWS API issue that applies to all 6000++ members to basic Python programming skills). Shouldn't it be self.cancelOrder(orderId, OrderCancel()) instead of self.cancelOrder([orderId], OrderCancel()) ? cancelOrder() defines orderId as an integer value and doesn't [orderId] make it a list of one integer value? ´³¨¹°ù²µ±ð²Ô ? ?
On Wed, Sep 11, 2024 at 10:44 AM, ds-avatar wrote:
|
|
Re: What is manualOrderCancelTime param of Eclient::cancelOrder( int id, String manualOrderCancelTime)
Hello DS,
?
Thank you for your response to my query. So if I understand correctly, should my call for cancellation of an order look like this instead?
?
self.cancelOrder([orderId], OrderCancel())
?
Kind regards,
Scott. |
|
Re: What is manualOrderCancelTime param of Eclient::cancelOrder( int id, String manualOrderCancelTime)
You should use OrderCancel() for the operand in question. This is how Juergen's suggestion of instantiating an object is translated to Python.
?
Seeing that you are highly dependent on the documentation you might consider installing the "stable" client API 10.19 which I believe most of docs are centered around.
?
Also while this group is dedicated mostly to the original IBKR's client API, when it comes to Python the excellent independent alternative ib_async package is arguably much easier to use. But even then limitations of a naive copy-and-paste approach without learning key concepts and practices of the underlying programming language will betray themselves pretty soon. (Note that beside Python, the original client API is also available in C, C# and Java, so there's plenty of choices that could be more suitable to your experience).
?
--
Best, DS |
|
Re: What is manualOrderCancelTime param of Eclient::cancelOrder( int id, String manualOrderCancelTime)
Hello ´³¨¹°ù²µ±ð²Ô,
?
Thank you for this additional information. I have done as you suggested and changed the call for order cancellation to the following:
?
self.cancelOrder([orderId], OrderCancel)
?
Unfortunately this results in the following error, which terminates the program:
?
type object 'OrderCancel' has no attribute 'manualOrderCancelTime'
?
I have taken a look at the source code for Python for order cancellation (order_cancel.py)? and it looks like this:
?
"""
Copyright (C) 2024 Interactive Brokers LLC. All rights reserved. This code is subject to the terms ?and conditions of the IB API Non-Commercial License or the IB API Commercial License, as applicable. """ from ibapi.const import UNSET_INTEGER
from ibapi.object_implem import Object from ibapi.utils import intMaxString ?
class OrderCancel(Object):
? ? def __init__(self): ? ? ? ? self.manualOrderCancelTime = "" ? ? ? ? self.extOperator = "" ? ? ? ? self.externalUserId = "" ? ? ? ? self.manualOrderIndicator = UNSET_INTEGER ?
? ? def __str__(self):
? ? ? ? s = "manualOrderCancelTime: %s, extOperator: %s, externalUserId: %s, manualOrderIndicator: %s" % ( ? ? ? ? ? ? self.manualOrderCancelTime, ? ? ? ? ? ? self.extOperator, ? ? ? ? ? ? self.externalUserId, ? ? ? ? ? ? intMaxString(self.manualOrderIndicator), ? ? ? ? ) ?
? ? ? ? return s
?
Unfortunately I am not well versed in Python beyond the basics from what I have learned from the sample code provided in the IBKR tutorials, so I am just unsure what I am doing wrong here and why this error is occurring. It is disappointing that the API documentation has not been updated by IBKR to reflect the changes made to this function from version 10.30+ so I at a loss as to how I can move past this error.
?
I am most grateful for your assistance.
?
Regards,
Scott.
?
|
|
Re: What is manualOrderCancelTime param of Eclient::cancelOrder( int id, String manualOrderCancelTime)
If in doubt, the source code is still the best documentation, Scott. I am not a Python practitioner, but I assume the OrderCancel class has a no-argument constructor that initializes the four fields with meaningful "empty" values. At least the Java implementation has one. Assuming you cancel orders infrequently, I'd replace the empty string "" parameter with something like new OrderCancel()?or the equivalent in Python. My framework already has a convenience method void cancelOrder( int orderId ) that hides the extra parameters from the business logic (since I don't need the manualCancelTime or OrderCancel logic). In that case, a single shared and constant OrderCancel object will work, too. ´³¨¹°ù²µ±ð²Ô ? ? On Tue, Sep 10, 2024 at 06:32 PM, <scott_hopgood@...> wrote:
|
Lalo F.