Please create an operator ID for each group of persons who operate/monitor the system at the same time.

Whenever an automated trading system submits an order message (incl. order revisions and cancellations), the message must include the ID of the team or individual who is operating/monitoring the system at that time.

Thanks for the pointer, I was able to get that to work. I was hoping I could just use a market data subscription to keep it up-to-date as with shares available to short. It seems very odd that they only provide historical data for fee rate and not the current value, but at least the data is available via the API, I can request a 1-minute bar from the last minute.

You are correct, Marco. Each clientId has its own sequence of orderIds and, since nextValidId() has a value of 1 when a clientId is used for the first time, the numeric values for orderIds for different clientIds can (and will be) be identical at times.

The technical requirement your client has to be aware of is that each placeOrder() call shall present an orderId that is higher than all orderIds the calling clientId has ever received in openOrder() or orderStatus() callbacks.

As long as a client receives only openOrder() callbacks for orders it placed itself, keeping a counter that is initialized from nextValidId() at connection time is sufficient. When a client terminates, TWS/IBGW will remember the highest orderId used in placeOrder() calls and assures that nextValidId() returns a value higher than that when it connects again later.

But there are cases where a client can receive openOrder() callbacks for orders placed by other clients (or TWS). In these cases, the client may need to bump the internal nextValidid counter accordingly. Let me quote directly from the TWS API documentation since it nicely describes this:

However if there are multiple client applications connected to one account, it is necessary to use an order ID with new orders which is greater than all previous order IDs returned to the client application in openOrder or orderStatus callbacks. For instance, if the client is set as the Master client, it will automatically receive order status and trade callbacks from orders placed from other clients. In such a case, any orderID used in placeOrder must be greater than the orderIDs returned in these status callbacks.

Alternatively if the function reqAllOpenOrders is used by a client, subsequent orders placed by that client must have order IDs greater than the order IDs of all orders returned because of that function call.?

The second part of that statement is what you need to be aware of. Say your client needs to be know about orders for the instrument is manages that are open when it connects, a call to reqAllOpenOrders() might generate openOrder() callbacks with orderIds that are higher than the nextValidId(). In these cases, simply bump the internal counter to that orderId + 1.

And to make this very simple and safe for all scenarios, just perform that test unconditionally for all openOrder() and orderStatus() callbacks regardless of why your client receives them.

Sounds complicated, but is really not.

There is also an API Global Configuration option called "Use negative numbers to bind automatic orders." Take a look at the tool-tip.

闯ü谤驳别苍

?

?

On Fri, Dec 27, 2024 at 09:36 AM, Marco wrote:

Hello 闯ü谤驳别苍,

thanks for your detailed reply. Yes I?confirm my counter(s) get initialized with the value from the automatic nextValidId() callback. It is not completely clear to me when you mention "in contact". Does it mean in case different clients can manage same order?

if the clients are independently managing different orders I can have independent?counters so in principle the same numerical orderId can be reused for different clients, am I correct?

thanks

Marco

On Fri, Dec 27, 2024 at 3:04?PM 闯ü谤驳别苍 Reinold via <TwsApiOnGroupsIo=[email protected]> wrote:

There is nothing wrong with your approach, as long as your internal counter gets initialized with the value of the automatic nextValidId() callback you receive when your client connects to TWS API.

If your client gets "in contact" with orders from other clients, you need to adjust your interal counter so that it is higher than the orderId of all orders your client sees. That is mostly important for client 0 and the master client since they receive openOrder() callback for orders placed by other clients or TWS in real time, but all clients might need to do that in case they request all open orders, for example, and the list contains order from other clients.

The simplest approach is that your openOrder() callback makes sure that your internal counter is always higher than all orderIds it sees.

闯ü谤驳别苍

?

On Fri, Dec 27, 2024 at 08:03 AM, Marco wrote:

Hi All,

one question on the orderId and the necessity of nextValidId function. From the documentation () it is stated that “if there are multiple client applications connected to one account, it is necessary to use an order ID with new orders which is greater than all previous order IDs returned to the client application in openOrder or orderStatus callbacks?”. so I expect that the nextValidId function is needed in case of multiple clients for one account. However i have created a program in python that handles orderIds internally without relying on the nextvalidid function. By launching multiple instances of it (each with different client id) I see no problems in handling orders (each client autonomously updating its orderId). What am I missing? Is nextValidId really needed?

thanks,

Marco

?