Overview

SabrTrader Plugin SDK

Build anything the platform supports — as a plugin.

SabrTrader is an extensible trading platform. Indicators, strategies, bar types, drawing tools, market-data connections, trading providers and more are all plugins: you compile a single .NET DLL against the public SDK, drop it in a folder, and the host discovers it on the next launch.

This documentation teaches you to build every plugin kind, from a short "hello world" to production-grade tooling. Each subject lives on its own page so you can read exactly the topic you need — use the menu on the left to jump straight to it. You never modify, or even see, the host's source code: you reference one NuGet package and implement small, well-documented contracts.

Who this is for. .NET / C# developers — and yes, vibe coders too. Every concept comes with small, copy-pasteable examples, and every example is preceded by an explanation of what it does and why. If you can describe what you want and read C#, you can build it.
Full example source on GitHub. Every standard indicator that ships with SabrTrader — 200+ real, working implementations — is open source under the MIT license. Read it alongside these docs, or fork it as a starting point for your own plugin. github.com/erwin-beckers/sabrtrader-indicators ↗

Start here

Two pages get you from zero to a plugin on a chart, and one page gives you the mental model that makes every later chapter click. Read them in order if you are new.

Install the SDK

Add the one NuGet package every plugin compiles against, target net10.0, and turn on auto-deploy.

Set up your toolchain →

Your first plugin

Write a complete minimal indicator, build it in Release, deploy it, restart, and see it draw on a chart — the full round-trip.

Build it end to end →

Core concepts

The plugin model, the contract assemblies, capability interfaces, series indexing, lifecycle phases and threading — the foundation under every chapter.

Learn the foundation →

What can I build?

The SDK surfaces the whole platform as contracts. Each plugin kind has its own chapter, and each chapter is split into focused pages — an overview, a "your first one" walkthrough, then one page per feature. Start anywhere; the chapters are independent.

📈 Indicators

Plot lines, bands, histograms and candles. Custom chart rendering, orderflow access, per-tick or per-bar calculation, panel placement, threshold lines, child indicators, multi-timeframe and toolbar menus.

Build an indicator →

🤖 Strategies

Automated entries and exits with managed orders, full ATM brackets (stop/target, breakeven, trailing, scale-in/out), optimizable parameters, backtest and live execution.

Build a strategy →

🕯️ Bar types

Custom candle aggregation driven by ticks or derived from another series — Renko, range, volume, Heikin-Ashi, or something proprietary of your own.

Build a bar type →

✏️ Drawing tools

Interactive chart annotations with anchors, hit-testing, editable properties and automatic persistence. Lines, shapes, Fibonacci level sets and patterns.

Build a drawing tool →

🔌 Venue plugins

Teach the platform a new venue — data feed, broker or crypto exchange: backfill, live ticks, depth and instruments, behind one plugin, one manifest and one session.

Build a venue →

💱 Trading providers

Route orders to a venue: place / cancel / modify / flatten, stream order and account updates, report fills and commissions, and declare your capabilities.

Build a trading provider →

📊 Market Analyzer columns

Add custom columns to the Market Analyzer grid — a computed value per instrument, with its own parameters and data type.

Build a column →

🔔 Alerts

Deliver alerts through a custom channel — e-mail, webhook, messaging or anything you can reach from .NET — behind one async contract.

Build an alert channel →

🕒 Trading hours & sessions

Session-aware logic: detect session open bars, the first bar of a session, and whether a bar time falls inside a configured window.

Work with sessions →

🏦 Broker venues

A broker is a venue that also routes orders: one plugin, its own trading port over your vendor client, and the components and contract kit that keep the order lifecycle honest.

Build a broker venue →

📒 Trade history

Persist and query fills, and backfill historical executions from a broker into the platform's trade-history store.

Work with trade history →

🎯 Options data & trading

Venue-agnostic option chains with IV, open interest and greeks, bounded snapshots for exposure analytics (GEX/DEX/VEX), streaming contract quotes, and atomic multi-leg orders from strategies.

Work with options →

📚 SDK reference

Every public type in the contract assemblies — interfaces, records, enums and attributes — grouped by namespace, with signatures.

Open the reference →

How the SDK is structured

One meta-package, SabrTrader.Sdk, brings in the three contract assemblies you compile against, plus an MSBuild target that can auto-deploy your built DLL. The contract assemblies hold only interfaces, abstract base classes, attributes, enums and data records — no engine code. The host supplies the engine at load time, which is exactly why your deployed plugin ships only its own DLL and never copies of these assemblies.

  • SabrTrader.Pipeline.Contracts — indicators, plots, series, bars, ticks, market depth, drawing tools, market-analyzer columns, alerts, and the venue-agnostic options data model.
  • SabrTrader.Pipeline.Venues.Contracts — the venue seam (plugin, descriptor, manifest, session) plus orders, positions, accounts, risk, ATM brackets, multi-leg option orders, the option chain SPI and trade history.
  • SabrTrader.Pipeline.Strategies.Contracts — the Strategy base class and its runtime context.

Core concepts walks through how these fit together: the plugin model, the "base class plus optional capability interfaces" pattern, series and bars-ago indexing, ambient providers, and the shared lifecycle every plugin kind follows.

How a plugin works

The mechanism is the same for every plugin kind, and it is deliberately simple. There is no plugin manifest, no registration call, and no host configuration to edit. You implement a contract, build a DLL, and the host finds it by inspecting the types inside. The four steps below are the whole story; the Building & deploying chapter explains each in depth.

  1. Reference the SDK. One NuGet package, SabrTrader.Sdk, brings in every contract assembly you need. You compile against pure contracts — interfaces, base classes and data records — never the engine itself.
  2. Implement a contract. Subclass IndicatorBase, Strategy, DrawingToolBase, or implement a discovery interface such as IVenuePlugin — the one export behind a market-data feed or a broker. The host constructs your type with a public parameterless constructor before applying any settings.
  3. Build & deploy. Output a net10.0 DLL and copy it — just the DLL — into the host's Plugins folder. An MSBuild target shipped in the SDK can do this for you on every build.
  4. Restart SabrTrader. The plugin loader scans the folder, discovers your types by the interfaces they implement, and registers them into the relevant catalog. Your tool now appears in the UI alongside the built-ins.
The golden rule of deployment. You deploy only your plugin DLL — never the SDK contract assemblies or the .deps.json file. The host already owns the contract types; shipping your own copies breaks type identity and your plugin silently won't load. The full reasoning is in Dependencies & isolation.

The pipeline at a glance

Everything is built on a small, allocation-conscious core. Two value types underpin the whole platform — a bar and a tick — and every plugin kind is a contract that produces or consumes them.

C#// One OHLCV bar — passed by value through the whole pipeline.
// StartUtc / EndUtc are true venue UTC. Start / End is the chart timeline
// (display-zone wall-clock when the host has stamped StartDisplay / EndDisplay).
public readonly record struct Bar(
    DateTime StartUtc, DateTime EndUtc,
    double Open, double High, double Low, double Close,
    long Volume, long TickCount,
    DateTime StartDisplay = default, DateTime EndDisplay = default);

The flow reads left to right: connections produce ticks; bar builders aggregate ticks into bars; indicators and strategies read the bar series and emit plots, signals and orders; the chart renders plots and drawing tools. Each layer is a contract you can plug into, and the SDK reference maps the full surface.

Conventions used in this guide

Marker Meaning
SIMPLE A minimal, get-it-working example.
ADVANCED Production features: rendering, parameters, multi-timeframe, ATM, persistence.
INTERFACE A contract type you implement or consume.