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 5The flags
From the bin's usage text:
--symbols— a comma list ofvikeSymbol=ibkrContractpairs, required; a bareSYMmeans the contract equals the symbol.--env—demo(whichpaperalso spells) orlive. The default isdemo, and the bin's own test names that as the one default whose direction is a safety property: a forgotten--envmust never reach a live account.--interval—1d,1h,5mor1m(default1d).--years N— how far back to page when--startis absent (default 5); it bounds the fetch whenhead_timestampis unavailable.--start— an explicit lower bound, epoch milliseconds orYYYY-MM-DD.--what— IBKR'swhatToShowfield:trades,midpoint,bid,askorbidask(defaultTRADES).--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.
The vike.io Data API
Two routes into data.vike.io — the paged /v1 REST API for cohort metrics and the hourly asset panel, and the Polymarket L2 Parquet archive — plus the store's rule for when two writers cover one window.
Polymarket
The venue serves no history, so its two collectors read an archive and your own raw-frame captures.