开云体育

I tried to use IDEAPRO to get the forex ratio for the BRL (Brazilian Real).

?

I got the classic error code 200:

?

Error. Id: 100

Code: 200

Msg: No security definition has been found for the request

?

I tried to reverse the contracts "symbol" and "currency" between USD and BRL - as the IDEALPRO exchange only returns some forex pairs if the symbol/currency is set up in a particular way.

?

In fact, IBKR's material doesn't list the BRL in the IDEALPRO exchange: https://www.interactivebrokers.com/en/index.php?f=2222&exch=ibfxpro&showcategories=FX&p=&ptab=&cc=&limit=100&page=1

?

I was surprised, however - Brazil is a big economy, and I thought having its currency forex ratio would be helpful for IBKR's clients.

?

Can someone suggest any other contract or approach to get the historical forex ratio for the Brazilian Real?

?

Thank you

Never tried (So I shouldn't answer) but I guess 3 things that make me thinking: don't waist too much time on that:

1- you will not pay more because you open different Client ID.
Client ID is a way to insulate some order processing methods etc ... it's a context intent feature, not a connection intent feature.

2- What is important is number of open socket to the server, and as you can only open one by server (that I know) ClientID doesn't help you.
Caveat:
On one machine you theoretically can open 4 sockets but on 4 different servers, by running GT+TWS with Paper and Real , BUT!! you will need as many different IB account as you want simultaneous connections.
?not worth the trouble.

3- You will not get better data rate, because with just a single connection you can (you will most assuredly) easily hit pacing limitations.
Thing like (but that is not the only one)
Theses limitation are aggregated at GW level or even worst if using TWS as it also involved what TWS displays. IB give you some slack on that but that's only slack, not commitments
Pacing limitations can be raised buying connection packs but even so IB have a ceiling on that.

In short:
Try first, because I will be surprised that connection speed will become your main issue.

Hmmm
My understanding of IB Forecast values trough API is that IB deliver same data as you may receive by email about Analyses forecast etc ... Theses are short term prediction.
2025 and more are most probably not something IB deliver (or I must say I don't know nor I see any place for a method to specify date to look for in the future)
Future (date) for IB is either next quarter or TTM.

This level of of anticipation are generally done trough a synthesis of frequency analysis + trend+ crystal ball prediction, these are more faith than fact.
I recommend that you take it from the most popular provider of prediction, at least you will see what most other people have on their radar.? Some providers have REST API so you should be able to automatize it.

So what is triggerPrice then?

TWS/IBGW logs are stored in the root of the "account" folder for the account that TWS/IBGW was logged into. That is a folder in "~/Jts" with 40 or so random looking characters. The log file for API messages is called something like "api.1697984914.20231022.092837.ibgzenc"

But all log files are encrypted so that the actual file does not help you. You'd go to Help->Troubleshooting->Diagnostics->APILogs in TWS/IBGW to decrypt los for the time you are interested in. You'll provide a file name of your choice for the decrypted logs.

闯ü谤驳别苍

• If the problem is somewhere in TWS or IBKR, you should see the same delay in the TWS log that your client experiences

• If the problem is somewhere in your client, you should see the usual sub-second delay between order placement and openOrder/orderStatus messages in the TWS API message log file, but much longer delays in your client

execDetails messages will only occur once an order actually fills (partially or completely). Depending on the order, that may take a while (for example if you place a limit order with a target price far away from the current bid/ask prices) but you should get openOrder/orderStatus callbacks immediately after placing the order and likely while the order is active.

闯ü谤驳别苍

That's exactly what I am looking for. Thank you.

The Execution returned on every fill has a field lastLiquidity whose possible values are:

None
Added("Added Liquidity")
Removed("Removed Liquidity")
RoudedOut("Liquidity Routed Out") [sic]

Maybe that's what you are looking for.

Does anyone know if there is a way to tell that my fills were making or taking liquidity?