Richard nicely described how you'd use the various order and trade related callbacks to manage your orders, and there is really nothing for me to add there.
Orders and trades do not happen in the vacuum and they are always related to an Account and a Position. TWS API has a rich set of requests, subscriptions, and callbacks that keep your client informed about those as well. Every trade changes the position so that you have a "second opinion" of the exact impact of an order (or a series of orders or modifications). You can simply compare the cumulative effect of a series of execDetails() callbacks with the change of the position over the same time frame.
Below a very simplified data model of how they fit together.
闯ü谤驳别苍
PS. Generally one Trade will receive one TradeReport. But for completeness the model indicates there may be more than one. In rare situations (and I never had that happen, but it may), TWS API clients may receive one or more TradeReport corrections through execDetails callbacks later in time. The documentation says:
Note if a correction to an execution is published it will be received as an additional IBApi.EWrapper.execDetails callback with all parameters identical except for the execID in the Execution object. The execID will differ only in the digits after the final period.
?
?
?
?
?
On Fri, Feb 14, 2025 at 01:01 PM, Richard L King wrote:
Rather than comment on the questions you’ve raised, what I’ll do here is just lay out the basic principles that underly the order management component of my trading platform, which I have honed over the past 22 years. I believe it is immune to all the situations you describe.
?
- Maintain a model in the client containing information about all current orders. This is the client’s view of the current state of affairs, which may not be the same as the reality at any moment because of the unavoidable asynchronicity of multiple cooperating (very) loosely--coupled components.
?
- Record the state of the model in a persistent data store that can be used to reconstitute the model after a restart of the client (for any reason). As a matter of implementation, I use a text file containing JSON-encoded records that reflect every order-related operation or event sent to or received from the API. This ‘transaction log’ can be replayed to reconstruct the model as it was at the time the last record was written.
?
- Update the model whenever an order is placed, modified, or cancelled.
?
- Update the model whenever an open order, order status, execution or error notification is received from the API. Note that it is execution notifications that are really in control of order state; open order and order status notifications merely provide confirmation, and an inconsistency would be a definite fault (see 6 below).
?
- As a practical matter, the representation of orders in the model is the actual order objects used in the place order call, updated on receipt with data from open order notifications.
?
- If at any point an irreconcilable inconsistency emerges (for example receipt of an open order notification for an order that is no longer in the model), this is a situation that needs to be investigated (typically a programming error): execution of the client must be immediately stopped since it is not safe to proceed from an indeterminate state. (This might surprise some, but where real money is at stake it is unwise to assume that the situation will somehow correct itself.)
?
- Provide an optional capability to ensure that every order always has a protective stop-loss. For a manual trading client, this may not be needed, because there is a least a strong possibility that there will be a human present to assess unexpected conditions and take corrective action if need be. For an unattended auto-trading system, the situation may be very different.
?
I think that more or less covers it, though there is a lot of detail I’ve glossed over.
?
Sounds like a lot of work? It is!...
?
?
Richard
?
