Broker-API — Unified Broker Data Layer

A command-line-first broker integration layer for market data, option chains,
and authentication — a shared adapter so every strategy bot speaks one interface
regardless of which broker is behind it.

Why it exists

Every bot in the suite needs the same things — a live quote, an option chain, a price history — but each broker returns them in a different shape. Broker-API is the adapter that normalizes broker-native connectivity behind one interface, so the strategy bots don't care whether a chain came from Schwab or Tradier. It keeps broker-specific tooling (OAuth, token refresh, symbol mapping, raw-payload inspection) separate from the strategies themselves.

Supported brokers

BrokerRoleStatus
SchwabPrimary. Quotes, option chains, price history, self-refreshing OAuth token flow, index/futures symbol normalization.Active
TradierEquities & options data (quotes, chains with greeks). Used as a secondary source and A/B comparison for options-only workflows.Active
E*TRADESandbox-first integration path — token setup and early quote testing; approved for equities/options data.Sandbox
TradeStationPlanned — an FCM with futures access, targeted for futures workflows once the adapter is built.Planned
IBKR (Interactive Brokers)Planned — broad multi-asset coverage for future expansion.Planned

Regulatory reality (why the split)

Broker capability isn't uniform, and the adapters reflect that:

What it does

Design approach

Command-line-first: small Python scripts, template env files, and fast iteration. The goal is easy local testing and confidence in the data before broker logic is wired into the larger alerting and strategy systems. It is an active adapter layer, not a polished general-purpose SDK.

Security

No live credentials are committed — client IDs/secrets, access/refresh tokens, and account numbers stay out of the repository. Checked-in env files are templates only, with blank values.

Disclaimer

For educational and research use. Not financial advice.

← About