Teach TradeStrike to talk to a new market-data venue: historical backfill, live ticks, order-book depth, open interest, summaries and instrument metadata — discovered through a credential-driven factory and bundled behind one interface.

The connection model

A market-data connection plugin is how you teach the platform to read a new venue — a futures broker, a crypto exchange, a vendor REST API, a CSV vault, anything that can produce bars or ticks. The pattern is deliberately small: there is no venue-specific plumbing to learn, only two core contracts, both declared in namespace TradeStrike.Pipeline.Providers. One advertises the source and collects credentials; the other is the source once it has them.

The split matters because the host needs to describe your provider before any credentials exist — to list it, to draw its form. That is exactly what the factory is for. Only after the user fills in the form does a live IDataProvider come into being. From there everything is capability-gated: you light up the flags you actually support, and the host probes the matching sub-interfaces, treating a null one as "this venue does not do that".

graph LR
  A["Plugin loader
scans assemblies"] -->|discovers| F["IDataProviderFactory"]
  F -->|RequiredCredentials| UI["Host renders
credentials form"]
  UI -->|Create(creds)| P["IDataProvider
(Disconnected)"]
  P -->|ConnectAsync| C["Connected"]
  C -->|Backfill / LiveTicks / Depth / ...| S["Chart / backtest / strategy session"]

Capabilities and optional surfaces

ProviderCapabilities is a [Flags] enum. A typical production provider advertises at least Backfill | LiveTicks; most also add InstrumentMetadata and, when the venue has a book, OrderbookDepth. Beyond those flagged core surfaces, an IDataProvider can opt into a family of optional feeds — open interest, level-1 summaries, fundamentals — each a property that defaults to null, so existing providers keep compiling and the host simply skips a feature when its property is null.

Market data only

Everything in this chapter concerns market data. Order routing is a separate contract — ITradingProvider in namespace TradeStrike.Pipeline.Trading — which hosts accounts, places and manages orders, and streams every state change back out as events. A real broker connection typically implements both sides under one provider key, but they are independent contracts: the OrderRouting capability flag exists on ProviderCapabilities only as a marker. The trading side has its own chapter; this one stays strictly data.

A tour of the chapter

The rest of the section walks the model one piece at a time: