Integrating five brokers behind one interface

No two broker APIs look alike. Some are clean REST APIs, some carry decades of legacy design, authentication ranges from simple API keys to signed requests with rotating credentials, and the assets themselves differ, stocks and options behave nothing like crypto pairs in terms of settlement, precision, or trading hours. Kyngly, a personal trading dashboard, set out from the start to support more than one broker, which meant the very first architectural decision mattered more than usual: don't let any of that variation leak past a single boundary.

One contract, several adapters

Every broker Kyngly talks to, currently Alpaca, Coinbase, Trading 212, and Interactive Brokers, plus EODHD as a market-data-only source, sits behind the same internal interface. The dashboard, the order-placement logic, and the backtesting engine only ever talk to that interface: fetch positions, fetch orders, place an order, cancel an order, get a quote. None of that calling code knows or cares whether the response underneath came from Alpaca's REST API or Interactive Brokers' considerably older and more idiosyncratic one.

Each broker gets its own adapter that implements the shared contract and absorbs that broker's specific quirks internally, translating its native response shapes into Kyngly's neutral internal model. Adding a sixth broker later means writing one new adapter against a well-defined contract, not touching the dashboard, the order logic, or anything else that already works.

A shared gateway, not five embedded SDKs

Rather than embedding each broker's SDK directly inside the main application, broker connectivity runs through a shared gateway sidecar that the core backend talks to over one consistent internal protocol. That separation keeps broker-specific dependencies, credentials, and failure modes contained in one place instead of scattered through application code, and it means a broker integration having a bad day, a rate limit, a slow endpoint, an outage, is isolated behavior at the gateway boundary rather than something that can directly destabilize the rest of the app.

Market data is just another adapter

EODHD isn't a broker at all, it's a market-data provider, but it fits into exactly the same adapter pattern as the trading connections. Quotes and historical data are just another capability behind the same style of interface, which means Kyngly's backtesting engine can pull historical price data through the identical abstraction it uses for everything else, rather than needing a separate, special-cased data-fetching path bolted on next to the broker code.

That consistency is what makes the backtester itself tractable: strategies like MACD, Bollinger Bands, Donchian channels, and momentum can be evaluated against real historical data and, later, run against live positions, using the same data and execution interfaces throughout, so a strategy that works in backtesting doesn't need to be rewritten to run for real.

The result is a dashboard that can grow the number of brokers and data sources it supports without the complexity growing at the same rate, each new integration is additive, contained, and speaks the same internal language as the four that came before it. Kyngly runs today against Alpaca in paper trading; the same architecture is what makes adding real, live broker connections later a matter of extending adapters rather than redesigning the system. More on what the dashboard covers today is on Kyngly's product page.