开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. Twsapi
  2. Topics

What is the exact limit on number of requests?

 

There are a couple of pages mentioning limits on historical requests and orders.?
?
The last link mentions that I should be able to place up to 50 requests per seconds.?
Meanwhile, when trying to sell iron condor using 4 independent orders, only some of them are being submitted and if I try to wait until all of them are placed, my script hangs.?
Then, I tried to add some delay between placing orders, and now all of them are placed as expected.?
?
for (var i = 0; i < orders.Count; i++)
{
? client.ClientSocket.placeOrder(...)
? await Task.Delay(15)?
}?
?
It seems that a delay of 15 milliseconds is enough.
Anything less than that gets stuck on the way to TWS.?
The same limitations seems to apply to "reqMktData" and "reqContractDetails" calls.?
?
Question?
?
How reliable is this hardcoded delay of 15 ms.?
Is there a recommended delay between requests anywhere in the docs??
 

Hi Andy. I also introduce 10ms of delay across orders. So far, working well for years. For other requests with `reqId`, I don't apply delay but I have a pacer that will introduce 1000ms delay every 45 requests. For my needs that's enough.

Hope it helps,
Daniel.

On Sat, Jan 11, 2025 at 3:13?AM Andy Sanders via <arteinvolo=[email protected]> wrote:
There are a couple of pages mentioning limits on historical requests and orders.?
?
The last link mentions that I should be able to place up to 50 requests per seconds.?
Meanwhile, when trying to sell iron condor using 4 independent orders, only some of them are being submitted and if I try to wait until all of them are placed, my script hangs.?
Then, I tried to add some delay between placing orders, and now all of them are placed as expected.?
?
for (var i = 0; i < orders.Count; i++)
{
? client.ClientSocket.placeOrder(...)
? await Task.Delay(15)?
}?
?
It seems that a delay of 15 milliseconds is enough.
Anything less than that gets stuck on the way to TWS.?
The same limitations seems to apply to "reqMktData" and "reqContractDetails" calls.?
?
Question?
?
How reliable is this hardcoded delay of 15 ms.?
Is there a recommended delay between requests anywhere in the docs??



--
Daniel
 

For child orders I used to get the error referring to parent order unavailability until I arrived by way of experiment to a pause of a whopping 800 ms after parent order submission (to be fair, I do not remember trying to minimize this interval vigorously because I don't need to).
?
In addition to this my order placing synchronized queue is set to either wait for order submission confirmation from TWS or skipping 20 ms after order submission when confirmation cannot be expected (i.e. for orders with Order.Transmit = false).
?
--
Best,
DS
 

Let me give a little different view than the previous respondents. In my experience, there is no need to pace requests or to add any delay when making TWS API requests with two documented exceptions (that I am aware of):
  • When requesting a large number of historical bar data with very small widths you need to observe the Historical Data Download limits
  • In case you receive error 10006 "Missing parent order" when placing orders (and I have never experienced this), the TWS API documentation says:
    "In some cases this can occur with bracket orders if the child order is placed immediately after the parent order; a brief pause of 50 ms or less will be necessary before the child order is transmitted to TWS/IBG."

There is a limit of 50 requests per second that all clients connected to the same TWS/IBGW together cannot exceed. Again, that is not per client but the aggregate of all clients. And many years back, TWS/IBGW would reject requests that exceeded that rate with an error message. Long-term users of TWS API have, therefore, implemented various pacing schemes so that their clients stay below that rate.

TWS API 9.79 (API level 156, released in early 2020) introduced the connection option "PACEAPI" that instructs TWS/IBGW to accept all client requests even those beyond the acceptable request rate without rejections and errors and to perform any required pacing internally. I have used that option ever since and have never had any issues with missed, dropped, or hanging requests.

Some time during the early V10 versions of TWS/IBGW (but well before when 10.19 became the "stable" version), "PACEAPI" became the default unless you explicitly disable it in the Global API Configuration screen.

If you experience "hangs" or orders that do not get placed properly without any error messages you might want to review your client code. Make sure that your code handles each and every error callback and, under no circumstance makes calls to sleep() functions that block the calling or all threads in your client. And most importantly, never do anything that blocks the TWS API callback thread.

I also make reqMktData() and reqContractDetails() calls that frequently go well beyond the 50 requests per second limit but I have never had an issue with that. Just to make sure I just re-ran one of my system integration tests that burst requests ContractDetails for 503 S&P 500 stocks:

  • It took 41ms to fire off 503 reqContractDetails() calls. That is a peak rate of more than 12,000 requests per second or one request every 82 microseconds
  • It then took 10.349 seconds for all 503 responses to come back. That is, in average, one response every 20.5ms or a rate of 49 request/responses pairs per second. I'd say the TWS pacer does a pretty good job.
The architecture of this test is simple:
  • There are no sleeps or delays in the code.
  • Each reqContractDetails() creates a object that is stored in a list of all outstanding requests.
  • Once ContractDetails objects arrive from TWS/IBGW they are forwarded to corresponding with the (?value) call.
  • In case an error callback is received for a request, the corresponding is marked (?ex)
  • The main thread can process the responses as the various s complete (or completeExceptionally) or it can ask to be suspended until all s in the list are complete.
  • All programming languages have similar (or even identical) concepts for routing responses to the corresponding requestors.

I'd suggest you make sure your TWS/IBGW does not disable PACEAPI and you trust the built-in pacer. Not only will that take complexity out of your client, but you will immediately take advantage of any request rate limit relaxation (that has been rumored to come in 2025). And traditionally, IBKR has silently relaxed various API related limits over the years.

Hope that helps
闯ü谤驳别苍
?
On Fri, Jan 10, 2025 at 08:13 PM, Andy Sanders wrote:

There are a couple of pages mentioning limits on historical requests and orders.?
?
The last link mentions that I should be able to place up to 50 requests per seconds.?
Meanwhile, when trying to sell iron condor using 4 independent orders, only some of them are being submitted and if I try to wait until all of them are placed, my script hangs.?
Then, I tried to add some delay between placing orders, and now all of them are placed as expected.?
?
for (var i = 0; i < orders.Count; i++)
{
? client.ClientSocket.placeOrder(...)
? await Task.Delay(15)?
}?
?
It seems that a delay of 15 milliseconds is enough.
Anything less than that gets stuck on the way to TWS.?
The same limitations seems to apply to "reqMktData" and "reqContractDetails" calls.?
?
Question?
?
How reliable is this hardcoded delay of 15 ms.?
Is there a recommended delay between requests anywhere in the docs??
 

On top of the (excellent) reply by 闯ü谤驳别苍, please be aware that the "50 messages per second" limitation applies to all messages combined. Do not think that you can send e.g. 50 placeOrder() and 50 reqMktData() in the same second! So, if you decide to code a message-pacer yourself instead of relying on the built-in pacer IBKR provides, you have to combine all outgoing messages from your application software into TWS/Gateway in this pacer.

1 - 5 of 5