Hermes · Research Arc · 2026-06-02

IBKR Internal Tooling — OSS Landscape Brief

Scope: single first-party IBKR Pro account Surfaces: Web API + TWS API Verified: gh api 2026-06-02

Lane: research, not adoption Backing: 4 axes / 793 lines Commit: 822e72e

Editor's note

What this is. Landscape scan of open-source software that can shorten the build of an in-house tool reading positions, P&L, and market data from Interactive Brokers. Scope deliberately narrow: a single first-party IBKR Pro account holding internationally-listed names (US, Frankfurt, LSE/AIM, Toronto, Johannesburg, Australia), data consumed in-house for dashboards and analytics, not redistributed to external clients. Shapes which OSS path is relevant — most public IBKR tooling assumes institutional advisor / introducing-broker scale (needs IBKR's compliance-gated OAuth) or hobbyist single-script use (never has to survive a 7-day production cadence). The "single-account, hosted, scheduled" middle is exactly where the spec's preferred First Party OAuth path sits, and where this brief focuses.

Why it was commissioned. The IBKR developer surface has more landmines than depth. The reference spec catalogs them: wrong auth path wastes days on a request-token flow you don't need; assuming free TWS quote view proves API entitlement burns the first market-data bill; the snapshot endpoint's pre-flight breaks every first integration once; multi-currency P&L tells two different stories at the same instant; ETF look-through is silently missing; daily server-reset disconnects long-running jobs in a window that varies by region. Not surprises to anyone who has worked with IBKR — but surprises each time, to every new IBKR integrator. Goal of this arc: short-circuit that learning curve by mapping which landmines are solved upstream (adopt OSS), which are unsolved (build), and which are decisions the operator must make explicitly (orient).

What this path achieves. Roughly two weeks of orchestration work on top of adopted plumbing produces working internal tooling. Plumbing = auth, REST/WebSocket clients, session keepalive, exchange-session calendars, FX rate sources, US-listed ETF look-through. Orchestration = position-pull pipeline, market-data pre-flight loop, FX audit-trail wrapper, subscription decision catalog, P&L source pinning. Greenfield alternative — reimplementing auth + keepalive + REST coverage from IBKR's own documentation — is weeks-to-months for plumbing alone, which is the work the OSS landscape has already done. Hermes lane discipline: research, not adoption. This brief picks the OSS pieces and characterizes the build surface; the trading-domain owner (plutus) is the adoption arc.

How to read. §1 = operator-facing scenario picks. §2 = why the auth-path fork dominates. §3 = language coverage map. §4 = adjacent OSS to adopt. §5 = what you write yourself (build surface). §6-§8 = cross-cutting risks, recommended adoption pattern, 8 open questions for operator before tooling work begins. Backing axes (793 lines, linked footer) hold per-candidate verification: every star count, last-push, license, 90d-authors pulled via gh api on 2026-06-02. No scraped README badges.

TL;DR

OSS covers the plumbing layer (auth, keepalive, REST/WS clients, session calendars, FX rates, ETF look-through for US filings). OSS does not cover the orchestration layer (position-pull pipeline, market-data pre-flight, multi-currency P&L attribution, exchange-session tagging, subscription decision catalog).

Adopt OSS for plumbing. Build the orchestration. Three viable adoption paths depending on auth choice and language. Spec's preferred path (First Party OAuth + Python) has the cleanest fast-track stack and lowest operational burden.

1. Top picks per scenario

All metrics verified via gh api repos/{owner}/{repo} + commits?since=2026-03-02 on 2026-06-02.

Scenario	Adopt	License	Health flag
Python + First Party OAuth SPEC PREFERRED	`Voyz/ibind` alone — skip IBeam	Apache-2.0	Beta · 427★ · 2 authors/90d · single-maintainer
Python + Client Portal Gateway	`Voyz/ibeam` + `Voyz/ibind` (canonical pair)	Apache-2.0 ×2	IBeam self-flags cred-storage risk
Python + TWS / socket (amd64)	`ib-api-reloaded/ib_async` + `IbcAlpha/IBC` + `gnzsnz/ib-gateway-docker`	BSD-2 + GPL-3 + MIT	YELLOW ib_async bus-factor=1, 0 main commits 90d
Python + TWS / socket (arm64 / Pi)	same + `manhinhang/ib-gateway-docker` (native arm64 CI 2026-05-17)	BSD-2 + GPL-3 + MIT	only candidate with documented arm64 CI
TS/Node + First Party OAuth	`quentinadam/deno-ibkr` (npm `@quentinadam/ibkr` + JSR)	MIT	2★ · solo · fork-and-vendor recommended
TS/Node + TWS	`stoqey/ib` + IBC + ib-gateway-docker	MIT + GPL-3 + MIT	316★ healthy
.NET cross-platform UNLOCKS SPEC §1 GAP	`dshe/InterReact` (.NET 10, Rx)	Apache-2.0	70★ · bus-factor=1 · very active
.NET + Web API + OAuth	`cquillen/ibkr-conduit` (storage-agnostic cred API)	MIT	2★ · 100 commits/90d · new but most-active

2. The auth-path fork dominates

Spec §2: biggest decision. Picks branch entirely on this choice.

1A · First Party OAuth

SPEC PREFERRED for self-managed single account

Stack: Voyz/ibind ALONE

No gateway. No Selenium. No Java. No Chromium.

RSA key + consumer key on disk (vault-mountable).

client.tickle() + check_health() cover keepalive natively.

Burden: one Python service.

1B · Client Portal Gateway

Stack: Voyz/ibeam + Voyz/ibind

Java CP Gateway in Docker + Selenium-injected creds + Xvfb.

network_mode: bridge mandatory. restart: 'no' required.

Cred storage acknowledged-bad. No first-class Vault / AWS SM / Keychain.

Choose only if exec already on Gateway OR OAuth RSA setup rejected.

1C · TWS / socket (fallback)

Stack: ib_async + IBC + ib-gateway-docker

Lower-latency. Daily auto-restart. Weekly logout.

ib_insync fork-graph resolved: ib-api-reloaded/ib_async wins.

Yellow flag: 0 main-branch commits 90d, bus-factor=1.

Plan pinned-version + internal-mirror from day one.

3. Language coverage matrix

Language	Web API	TWS	Note
Python	STRONG IBind canonical	STRONG ib_async canonical	Default choice — both surfaces covered
TypeScript/Node	VIABLE quentinadam (solo, 2★)	STRONG stoqey/ib 316★	Server-side dashboard fit; fork-and-vendor on OAuth
C# / .NET	VIABLE ibkr-conduit new	STRONG dshe/InterReact	Unlocks Linux/Mac — spec §1 gap closed
Go	NO-PATH	STRONG scmhub/ibapi+ibsync	Web API gap is real (gomisha dormant 2021)
Rust	NO-PATH	STRONG wboayue 322★ (most-active non-Py)	v3.0.1 released today
Java (community)	NONE	(use official Java)	Community converges on IBKR's official
R	NONE	CANONICAL DORMANT IBrokers CRAN	TWS only; `lbilli/rib` active-niche
Julia	NONE	VIABLE Jib.jl solo	TWS only
Kotlin (native)	NONE	(use JVM/Java)	No idiomatic Kotlin client
Elixir	NONE	EXPERIMENTAL	Single-maintainer hobbyist only

Pattern: Web API community coverage is nearly absent outside Python and TypeScript. Any other language → IBeam + Gateway + hand-rolled REST/WS, or shell to Python IBind sidecar.

4. Adjacent stack (adopt these)

FX rates · date-pinned audit trail

alexprengere/currencyconverter — ECB daily rates 1999→today.

Pair with py-moneyed for type-safe Money objects.

Apache-2.0 / BSD-3 · committed 2026-06-01

Service-grade rate source

frankfurter.dev (api.frankfurter.dev) — no-key ECB proxy.

MIT · 1539★

ETF look-through (US, REDISTRIBUTABLE)

dgunning/edgartools — N-PORT + 13F, EDGAR-derived.

Only OSS source clean for redistributive outputs.

MIT · 2264★ · active 2026-06-01

Exchange-session tagging

rsheftel/pandas_market_calendars — 50+ exchanges.

Covers XFRA, XTSE, XASX, XLON, XTKS, XHKG.

MIT · 972★ · active 2026-05-27

Production reference stack

omdv/ibkr-trading — Docker + k8s + Terraform + Helm.

Pair with Voyz/ibeam as the auth container.

MIT · most-complete production reference

Modern FastAPI + MCP pattern

rcontesti/IB_MCP — FastAPI + FastMCP + auto-tickle.

Canary signal: IBeam+IBind+FastAPI as community de facto.

MIT · 127★

5. Build surface — what no OSS solves

Plumbing well-covered. Orchestration is the actual build.

Position-pull pipeline ~1-2 days
Call /portfolio (lighter session req), normalize position shapes, persist daily snapshots.
Market-data pre-flight orchestration ~1-2 days
Spec §4 trap: first /iserver/marketdata/snapshot call primes stream, returns nothing. Must prime, tolerate empty, retry. Batch around Market Data Lines cap.
Multi-currency P&L attribution + FX audit trail ~1 week
Spec §5. py-moneyed + currencyconverter is a 2-lib combo, not a packaged solution. Emit {position_id, local_ccy, base_ccy, rate, rate_date, rate_source, snapshot_ts} per IBKR conversion.
Exchange-session-state tagger ~1 day
Thin wrapper on pandas_market_calendars producing pre_market | open | break | after_hours | closed per position.
Subscription decision catalog ~1-2 days · HIGHEST-LEVERAGE
Zero OSS prior art. Build YAML/JSON {exchange × asset-class × pro-non-pro × API-allowed × $/mo} from IBKR pricing pages.
P&L source pinning + reset documentation ~½ day
Spec §5: TWS Account Window vs Portfolio Window disagree by design. Pin one source.
Daily server-reset scheduling in cron/k8s
Spec §3. Confirm reset window vs job timezone; avoid auth-into-maintenance-gap.

Total: ~2 weeks orchestration on top of adopted plumbing.

6. Cross-cutting risks

6A · pyCrypto security caveat — fleet-wide for first-party OAuth

Voyz/ibind documents the IBKR-provided pyCrypto code is unmaintained with known CVEs. Maintainer notified IBKR. Every first-party OAuth reference inherits this (nsirons, datawookie, marchenko). Decision needed: accept risk OR fork-and-replace crypto layer (pyCrypto → cryptography library, bounded engineering work).

6B · ETF look-through redistribution trap

EDGAR-derived (edgartools) is the only ETF-holdings source with clean redistribution rights. Every vendor scraper (nikulpatel3141/ETF-Scraper, JakubPluta/pyetf, druzsan/justetf-scraping) is MIT-or-none on the library, but data is governed by source-vendor TOS (iShares, etfdb, justETF). Treat vendor scrapers as internal-research tools only. Never re-emit downstream.

6C · Bus-factor concentration

Single-maintainer across axes: IBind/IBeam (Voyz), ib_async (Matt Stancliff), gnzsnz/ib-gateway-docker (cross-contributor to ib_async AND IBC — concentrates risk), dshe/InterReact, cquillen/ibkr-conduit, quentinadam/deno-ibkr, wboayue/rust-ibapi. No multi-vendor-backed OSS exists in the IBKR space. Closest: QuantConnect/Lean (commercial backing), pandas_market_calendars (institutional breadth). Mitigation: pin versions, vendor-fork the auth client, plan maintenance as TCO.

6D · Beta status across canonical projects

Both IBind and IBeam carry "currently being beta-tested" disclaimers. Production scheduled jobs reading positions and (especially) market data with real cost-per-line should pin a release and budget for patching forward if upstream stalls.

7. Recommended adoption pattern (research-lane, advisory)

Path: Python + First Party OAuth 1.0a

Auth + REST/WS:    adopt  Voyz/ibind (alone — no IBeam)
Session calendars: adopt  rsheftel/pandas_market_calendars
FX rates:          adopt  alexprengere/currencyconverter + py-moneyed
ETF look-through:  adopt  dgunning/edgartools (US-listed; flag non-US gap)
Reference stack:   read   omdv/ibkr-trading (k8s+Terraform+Helm)
Modern pattern:    read   rcontesti/IB_MCP (FastAPI+FastMCP+auto-tickle)

Build (orchestration layer):
- Position-pull + persistence pipeline       (1-2d)
- Market-data pre-flight loop                (1-2d)
- FX audit-trail wrapper                     (1w)
- Exchange-session-state tagger              (1d)
- Subscription decision catalog YAML         (1-2d)  ← highest-leverage
- P&L source pinning                         (½d)
- Daily-reset scheduling                     (½d)

Total: ~2 weeks orchestration on top of adopted plumbing.

Alternates: TS/Node + OAuth via quentinadam/deno-ibkr (fork-and-vendor) · Python + Gateway (IBeam + IBind) if OAuth RSA rejected · C# + InterReact + ibkr-conduit if .NET mandated.

8. Open questions for operator / plutus

Auth path — OAuth or Gateway? Spec §2 strongly recommends First Party OAuth for self-managed accounts. Confirm before proceeding.
Language — Python (default, broadest OSS) or TS/Node (fork-and-vendor burden) or C# (only if .NET in-stack)?
pyCrypto security caveat — accept risk, fork-and-replace, or block on operator decision? Affects every first-party OAuth path.
IBC GPL-3.0 — acceptable for internal-only? Forecloses future product paths that embed IBC binaries.
Subscription decision catalog — build now (1-2d, no OSS prior art) or defer? Would be Arsenal-publishable.
FX audit-trail library — fleet-shared or one-off? Plutus also touches IBKR — candidate for Arsenal if shared.
Deployment target — amd64 (gnzsnz) or arm64/Pi (manhinhang)? Only matters if Gateway path chosen.
Lane handoff to plutus — trading-domain adoption owner. Hermes can file return-handoff with BRIEF + 4 axis files + 5 build-gap tasks pre-scoped.

9. What this brief does NOT cover

Execution / order routing — read-only positions + market-data per spec scope.
Strategy backtest frameworks — QuantConnect Lean appears (axis-C) as OSS-on-.NET signal, not adoption proposal.
End-of-day flat-file Reporting Integration (spec §7) — separate research arc if operator confirms it covers enough use case to reduce live-API cost.
Real-time risk / margin / orders — latency-sensitive surface, TWS-only territory.
Dashboard / Slack / Discord front-ends — downstream consumers of orchestration layer.