Must be brand-new then. It is in TWS and IBGW 10.30.1u on Linux.

?

?

On Fri, Mar 7, 2025 at 08:39 AM, ds-avatar wrote:

I don't have this option in TWS 10.30.1t and IBGW 10.30.xx.

?

--

Best,
DS

?

?

On Thu, Mar 6, 2025 at 08:57 PM, Henk Visser wrote:

All,

?

I am trying to get some basic functionality working with the Wall Street Horizon API (using the TWS API) but there seems to be some fundamental items that I am missing.

?

I am referencing the documentation here:

?

?

I feel I need more information than what is provided here.? I was hoping to find a more detailed tutorial.

?

?

The example shown in the documentation shows:

?

?

What exactly happening here? It is dumping the entire calendar of data? Any further explanation on this I would appreciate.

?

?

What should I be doing at this point? From the documentation this looks to return specific event types.? the print() returns a lot of data that looks unfiltered and not focused on what I am looking for.?

?

?

The example in the documentation shows the call as the following.

?

self.reqWshEventData(1101, eventDataObj)

?

I am not sure here about the eventDataObj. The documentation states that "When making a request to the Wall Street Horizons Event Calendar with the API, users must create a wshEventData Object."? In the API documentation I don't see any an example of how to create this eventDataObj.

?

?

?

How do I filter this to only show data for a specific stock?? Is this related to the conID that would be part of the wshEventData?

?

Thanks for any information on this.

?

?

?

?

?

?

def wshMetaData(self, reqId: int, dataJson: str):
  print("WshMetaData.", "ReqId:", reqId, "Data JSON:", dataJson)

def wshMetaData(self, reqId: int, dataJson: str):
  print("WshMetaData.", "ReqId:", reqId, "Data JSON:", dataJson)

?

?

Thanks for verifying.? Disappointing. For bills, the name of the instrument doesn't have the date in it. But for bonds, I can pass the maturity date from the name and have had some luck converting that to something I can use in my software.?

Sure - Right now, in my portfolio and in my risk management software, I am trying to find out the maturity for:?

TBILL:? ?CON_ID: 756373753? ??This is a Jul 24, 2025 91279PF8 contract, which I can see in my portfolio. And I can use IBKR TWS platform to ask about the description, which comes up with CUSIP, ISIN, Maturity Date etc (from the trading platform, not the API).? ?Ideally, I would be able to get that symbol string, and parse the maturity date from the contract details in the API. But I don't see it in my request of contract details.? ? From the platform, description comes up with a msg box - would love to get the Maturity Date in the API!

Underlying	????	US-T	?
Coupon	????	No Coupon	?
Currency	????	USD	?
?
Bond?Description
Symbol	????	IBCID756373753	?
Security?Type	????	BILL	?
Exchange	????	SMART	?
CUSIP	????	912797PF8	?
ISIN	????	US912797PF82	?
Issue?Date	????	JAN 23 '25	?
?
Details
Exchange?Listed	????	No	?
?
Issuer?Information
Bond?Issuer?Type	????	GOVT	?
Face?value	????	1000.0	?
Maturity?Date	????	JUL 24 '25	?
Contract?ID	????	756373753	?
Min.?Tick?Size	????	0.00001????

I have scoured the API (C++) and am trying to figure out how to find the maturity date of a TBILL.

I have stepped through the fields of ContractDetails in my Visual Studio IDE, but any fields such as expiration , maturity etc are empty.

For bonds, I can look at the name and parse the string, but for T BILLS, it seems like I am out of luck. I just have the contract ID.

?

Has anybody solved this issue?

?

Thx,

Dave Linenberg

I have the same issue.? The reqIds didn't respond back anything.? Have you solved it?

I know this is an old post, but this happened to me today. I'm testing my code using a paper account and running TWS so I can see the positions in TWS. For testing it only opens positions of a single share, long only. And I have it set up to cancel all open orders and sell all open positions just before the close of the regular trading hours. There were 17 open positions and all but one were closed as expected. Just one position, a stock with ticker BTOG, was not closed. I received several errors saying: "Order rejected - reason:The contract is not available for short sale."? This was despite the fact that the open position was long 1 share and the closing order was a MARKET order to sell 1 share. After stopping my code I placed a LIMIT order manually to sell 1 share. It was filled to close the position.

?

The error message makes no sense, but I suspect the market order was rejected because it could not be filled immediately on this illiquid stock whereas the limit order waited for a bid to show up.?

To disable auto pacing, don't send "+PACEAPI" during client connection AND select the option "Reject messages above maximum allowed message rate vs applying pacing" in the global API configuration in TWS or IBGW.

?

?

?

On Tue, Mar 4, 2025 at 02:00 PM, <tbrown122387@...> wrote:

Thanks Jurgen. This is very informative. So turning +PACEAPI off, gives me a little wiggle room. Got it. I am more interested in the ability to revise orders with placeOrder(), but as you mention there will always be plenty of caveats with this sort of thing.?

?

?

?

?

?

?

Note, first time one needs to run the code two times to generate that "history" file, so the next tests can have that "latest" (=history) timestamp to compare against and output error in case they are not in order.
?

?

?

?

I went into the API Global Settings in TWS and IBGW today (I rarely need to go there) and that reminded me of an option you might be interested in. It allows you to control whether TWS/IBGW should remember and resubmit orders they receive while connectivity with IBKR is lost or not.

?

?

On Sun, Feb 16, 2025 at 11:17 PM, <joshi.tarun3107@...> wrote:

Before we start, a few disclaimers and initial thoughts:

• The actual implementation of the TWS/IBGW built-in API request pacing is undocumented and technically not part of the API. It can change at any time without notice (and has) but has been stable for years and permits sustained request rates of at least 50/sec for extended periods of time. So you can make 250 requests in 5 seconds.
• The TWS/IBGW API request limit relates only to reqXXX() calls by the clients (e.g. messages from the client to TWS/IBGW) and not to the response callbacks that result from those requests. For example, with multiple simultaneous real-time market data subscriptions for busy instruments (especially with TickByTick and Level II), I see callback rates for extended periods of time of well above 10,000 response callbacks per second.
• The API request limit is applied to the combined rate of requests for all clients simultaneously connected to the same TWS/IBGW. Implementing your own pacing scheme needs to take that into account and may have to coordinate the request rates for multiple clients.
• It may be possible for some simple work loads to exceed the 50 requests/s limit for brief peak times considerably (see below), but it will be a fragile undertaking with the risk of being disconnected by TWS/IBGW at will. ?It feels like you will waste your time and you should stick with auto-paced connections with TWS/IBGW.

With that said, here some observations from a few quick tests with one of my system test tools against stable TWS 10.30.1u. The tool makes a configurable number of reqContractDetails calls at the fastest possible pace and monitors and tallies the resulting responses and errors. In order to focus on the connection between the tool and TWS/IBGW, all requests are made for the same instrument. That makes it possible for TWS/IBGW to respond with a locally cached ContractDetails object and minimizes the need for communication between TWS/IBGW and the IBKR infrastructure. This is an artificial work load and you cannot expect that the results I present work for more complex tasks such as order placement.

When the test tool (client) is configured to exceed the allowed rate significantly, TWS/IBGW send up to two "error #100 - Max rate of messages per second has been exceeded” and disconnects the client if the rate is still exceeded after the second error message. It takes approximately 500ms from the start of the test run for the first error and another 500ms for the second error, though times differ between runs considerably.

In my setup and with a sequence of reqContractDetails calls for the same instrument, a rapid fire of 750 requests causes two error messages but no disconnect, while a run with 1,000 requests causes disconnects. Below a couple charts that show the timing of requests and responses for seven runs. This was not a controlled experiment just a few runs on two different client computers (one co-located with TWS in the same Linux instance in the cloud and one running remotely in my development environment with Wi-Fi, cable modem, competing with other traffic, ssh tunnel, ..) and during different ?times over the weekend (more quiet times earlier on Sunday as well as runs after 17:00 US/Central when futures were trading in Chicago already).

Here some highlights:

• It took the faster (client) computer in average 62ms to fire off 750 requests (82us per request). The slower computer took 146ms (195us per request).
• TWS responded with a first "error #100" within 500ms to 600ms after the start of the tests. By that time, all requests had been fired off "long time" ago.
• The second "error #100" arrived between 1,000ms and 1,600ms after the test start.
• All 750 requests resulted in a contractDetails() and a contractDetailsEnd() callback within an average of 2.4 seconds (min 1.4s and max 3.5s)
• Run #2 is an outlier for request time (slower computer) and run #3 is one for the response times (slower/higher latency network between TWS and IBKR).?

Again, don’t expect that you can extend this very artificial benchmark to any serious and meaningful work load.

闯ü谤驳别苍

?

?

?

On Sun, Mar 2, 2025 at 09:21 AM, <tbrown122387@...> wrote:

It sounds like you both are talking about the +PACEAPI thing. I want to turn that off and manage everything myself.?

250/5 sounds promising. I’ll poke around and report back with my findings.?

Have you seen how IBKR describes it themselves: ?

Nowadays you don't really need to worry about it any longer as the API has a built-in message pacer. Its task is to prevent you from going to fast: it will buffer the messages that exceed the limit.