Order visibility, executions, and history

There is no single “orders from the last 24 hours” call. Each surface has a different clock, ownership rule, and retention boundary.

Visibility matrix

Surface	What it contains	Important boundary
ib.trades()	Trade objects currently known to this IB instance	In-memory session projection assembled from startup and callbacks.
ib.openTrades() / openOrders()	Known trades/orders in an active status	Only orders visible to this client/master configuration; preferred over re-requesting.
reqOpenOrders()	Active orders submitted by the same client ID; client 0 can bind manual TWS orders	Snapshot can be stale in ib_async; never returns filled/cancelled orders.
reqAllOpenOrders()	Currently active API orders across client IDs	Other clients' returned orders are not automatically kept synchronized and are not thereby owned/modifiable.
reqAutoOpenOrders(True)	Future manual TWS orders bound to API client 0	Only client ID 0; binding can assign negative API order IDs depending on TWS setting.
reqCompletedOrders(apiOnly)	Orders no longer modifiable for the current day	Includes fills, rejects, and cancellations; not an unlimited history. Server version 150+.
reqExecutions(filter)	Executions matching server-supported filter scope	Filter time is a lower bound; returned availability is not a durable ledger guarantee.
ib.fills() / executions()	Fills/executions synchronized into this IB instance	Explicitly “from this session” in the library; lost when wrapper state resets.
Flex report	Activity statement generated by IBKR reporting	Asynchronous report system with configured date/account scope; best for back-office reconciliation, not live control.

Official documentation describes reqCompletedOrders as orders “for the given day.” That is a trading-day/current-day boundary, not a rolling 24-hour SLA. Do not infer yesterday's order will remain visible merely because it is less than 24 elapsed hours old.

Client IDs and ownership

An API order is bound to the client ID that submitted it. The same client ID reconnecting can recover its active orders. A Master API Client ID configured in TWS can receive activity from other API clients. reqAllOpenOrders broadens a snapshot but does not transfer modification rights. Client 0 can bind manual TWS orders and, with reqAutoOpenOrders, future manual orders.

API orderId is not a global durable key. It is scoped to an API client and must be greater than IDs already observed/used under the relevant ordering rules. permId is assigned by TWS/IBKR and is the preferred cross-session order correlation key. It can be absent before acknowledgement. Fills use execId.

Execution filtering

from ib_async import ExecutionFilter

fills = await ib.reqExecutionsAsync(
    ExecutionFilter(
        clientId=0,
        acctCode="DU1234567",
        time="20260714 09:15:00 Asia/Kolkata",
        symbol="",
        secType="",
        exchange="",
        side="",
    )
)

Empty fields mean no filter for that dimension. The time format/timezone must be accepted by the connected TWS version. Client-ID visibility differs: a master client can receive broader execution callbacks, while a filtered request's behavior depends on client/account permissions. Commission reports can arrive after execution details.

Durable schema

At minimum persist:

• application intent/idempotency key and strategy/reference;
• account, qualified contract snapshot, original and latest order fields;
• client ID, API order ID, permId, parent permanent/API IDs, OCA group;
• every status/error with receive timestamp and source;
• fills keyed by execId, execution time, quantity/price, and later commission;
• connection epoch and reconciliation run IDs.

Do not use mutable status as a fill ledger. Derive filled quantity from deduplicated executions and reconcile against orderStatus.filled.

Startup reconciliation

1. Establish the socket and complete connectAsync synchronization.
2. Fetch/observe open orders under the intended client/master policy.
3. Fetch current-day completed orders when supported.
4. Fetch executions from a conservative overlap before the last durable execution time.
5. Deduplicate by execId; attach by permId/order IDs with account checks.
6. Compare durable working intents with live working orders.
7. Mark unknown/missing cases for investigation—never automatically resubmit solely because an order is absent.
8. Reconcile positions and cash against the execution ledger and periodic Flex statements.

The overlap is essential because timestamps, reconnect boundaries, delayed callbacks, and corrections can otherwise create gaps. Idempotent upserts make overlap safe.

Corrections and busts

Execution corrections can be reported with related execution identifiers and updated values. Store versions/events rather than assuming an execId is forever immutable. A cancelled order may still have partial fills, and a fill can race with cancellation acknowledgement.

Official sources: open orders, executions and commissions, and IBKR Campus completed orders.