About broker integration — Quantstrip Docs

No BrokerBase class, broker registry, or configuration switch exists. References to other brokers in prior documentation were placeholders; no implementation exists in this codebase.

How IBKR is wired in

The integration lives entirely in strategy-script code, under Data\clients\IBKR\. It is not part of the dashboard or the core quantstrip module. Two files:

ib_connect.py — a synchronous wrapper class, IB(EWrapper, EClient), around the official ibapi package. Converts IB's asynchronous req.../callback API into blocking get_... methods.
ib_objects.py — factory functions (ib_contract, ib_order) that build the Contract/Order objects ibapi expects.

Strategy clients import from these two modules directly (from IBKR.ib_connect import IB), with no registration step. See Integration templates for the full API surface.

The pattern for a new broker

No formal interface exists to implement, but the existing structure is consistent:

A new folder under Data\clients\, e.g. Zerodha\.
A <broker>_connect.py with a wrapper class exposing blocking get_... methods for whatever that broker's SDK offers asynchronously or natively synchronously — positions, orders, executions, account data.
A <broker>_objects.py with small functions that build that broker's native contract/order objects from plain arguments.
Client scripts that import from those two modules and write into Quantstrip's schema via db_handler — insert_order, insert_execution, insert_position_event, insert_commission — following the same pattern as the IBKR examples, so downstream pages (Trade Operations, Reporting) function identically regardless of which broker produced the data.

Downstream pages — Reporting, Trade Operations, Client Monitor — read Quantstrip's schema, not broker-specific data. A new broker integration is responsible for writing data into that schema correctly; no other part of the application needs broker-specific knowledge.