vike
Data providers

IBKR historical

Paging IBKR historical bars through a running TWS or IB Gateway into the store as kind=bar under venue=ibkr — the offline twin of the live feed, behind the ibkr feature.

ibkr_backfill is the one venue-direct collector that needs a running desktop client rather than a public endpoint. Its header (crates/vike-backfill/src/bin/ibkr_backfill.rs) states the shape: it pages vike_ibkr::HistoricalFetcher — bounded below by the contract's head_timestamp, or an explicit --start — for a symbol set and interval, and ingests each window as kind=bar under venue=ibkr, idempotent per window. It needs a running TWS or IB Gateway, and the header adds why that is enough: its login is the entitlement, and history is looser than realtime. The bin is built only under the ibkr feature, which crates/vike-backfill/Cargo.toml enables together with vike-ibkr/ibkr-socket — the vendored ibapi client — so a default build never compiles it.

cargo run -p vike-backfill --features ibkr --bin ibkr_backfill -- \
    --env demo --symbols AAPL=AAPL.SMART.USD,MSFT=MSFT.SMART.USD --interval 1d --years 5

The flags

From the bin's usage text:

  • --symbols — a comma list of vikeSymbol=ibkrContract pairs, required; a bare SYM means the contract equals the symbol.
  • --env — demo (which paper also spells) or live. The default is demo, and the bin's own test names that as the one default whose direction is a safety property: a forgotten --env must never reach a live account.
  • --interval — 1d, 1h, 5m or 1m (default 1d).
  • --years N — how far back to page when --start is absent (default 5); it bounds the fetch when head_timestamp is unavailable.
  • --start — an explicit lower bound, epoch milliseconds or YYYY-MM-DD.
  • --what — IBKR's whatToShow field: trades, midpoint, bid, ask or bidask (default TRADES).
  • --store — the hist-store root, resolved through the store's ladder: $VIKE_HIST_STORE, then a $VIKE_SETTINGS_DIR-declared project, then <repo>/market_data/hist.
  • --pacing-ms N — the sleep between window requests, to stay inside IBKR's historical pacing limits (default 10000).

Credentials come from the credential store: the usage text names IBKR_{DEMO,LIVE}_ACCOUNT in <project>/settings/secrets.env as required beside the running gateway.

How it is split

crates/vike-backfill/src/ibkr.rs is the pure planning half — window sizing, paging and commit keys — fixture-tested with no network, mirroring the EOD and pmxt collectors' shape of one fixture-tested planner file. The bin drives HistoricalFetcher over those plans and ingests each window through HistStore::append_bars. The fetcher itself lives in the bridge: crates/bridges/vike-ibkr/src/historical.rs's header describes a public historical-bar seam that owns a dedicated ibapi connection, pages historical_data bounded below by head_timestamp, and returns vike_model::Bars — so the collector never names an ibapi type — reusing the same symbology, bar-size mapping and bar mapper as the live feed. It is behind ibkr-socket, where ibapi exists.

The collector is the offline twin of the live feed, and it is live-verified on paper: the proof vehicle is crates/vike-backfill/tests/ibkr_backfill_smoke.rs, whose header calls itself the human vehicle to verify the historical wire shapes before a real backfill run. It is #[ignore]d and self-skips without a config or a running Gateway, so nothing in CI ever runs it.

One data client id, three consumers

Three call sites open a connection on cfg.data_client_id: the mount-time properties fetch (crates/bridges/vike-ibkr/src/properties.rs's fetch_ibkr_properties), the live feed (crates/bridges/vike-ibkr/src/market_feed/mod.rs), and HistoricalFetcher::connect. Only the first pair is sequenced by construction — the properties doc records that its connection is a transient one-shot, "fully torn down before the live market-data feed … claims that same id, so it never contends the feed", and it says nothing about a backfill. A backfill run beside a live feed on the same configuration contends for the same id.

Where it sits in the capability table

crates/vike-backfill/src/caps.rs's row for (Venue, "ibkr") is BARS_ONLY, with the pipeline written beside it: HistoricalFetcher → vike_model::Bar → append_bars. Like every venue-direct source, it cannot repair a recorded trade or book gap; that is the finding the table's header exists to make visible, and the reason the vendor lanes on Databento exist for equities and futures history at tick resolution.

The IBKR venue itself — the mount, the two transports, reconciliation — is documented under venues; the ibkr_mount binary that runs a real mount is on mount-bins. The bar kind this collector writes is under concepts/data.

On this page