How to add a second broker without a rewrite

The second broker is where custom trading stacks go to die. The first integration feels like an achievement. The second one reveals that everything you built quietly assumed there would only ever be one.

​

Why the second broker hurts so much

Your first broker shaped your whole codebase without you noticing. Order payloads match its formats. Error handling matches its error codes. Your position tracking mirrors its lifecycle, and your event handlers expect its websocket messages. Broker two disagrees with all of it. Different field names, different order states, different ideas about what a partial fill looks like, different authentication, different rate limits. So you do what every team does: you start writing an adapter layer. One interface, two implementations, and a growing pile of special cases. Congratulations, you are now an infrastructure company. The adapter layer needs tests, monitoring, and maintenance every time either broker changes anything, and it still only covers two brokers.

​

The config change approach

Anthid takes a different path. Your strategy talks to one API for order execution, connectivity, live event streams, and risk controls, and the brokers sit behind it. You describe the outcome you want as an intent, and Anthid handles retries, failures, reconciliation, and each broker’s quirks for you. Alpaca and Lightspeed are connected today, with more on the roadmap. Adding a second broker is a config change, not a rewrite. You add the new broker’s credentials to your configuration, and your strategy code stays exactly as it was. It never knew which broker it was talking to in the first place, so it has nothing to relearn.

​

What stays the same

Everything you actually care about. Your strategy logic is untouched. Your event handling is untouched, because every broker’s events arrive in the same normalized stream regardless of where the fill happened. Your records stay coherent too: the durable historical ledger keeps events from both brokers in one place, so “what happened yesterday” has a single answer instead of two logs in two formats. Your risk controls also carry over. Trading windows and order size limits are enforced by the platform before any order leaves, and they apply no matter which broker is on the other end. You do not rebuild your safety net per broker.

​

What to check before you flip the switch

One honest caveat. Brokers differ in what they accept, and Anthid does not paper over that: an unsupported combination of order type, destination, or time in force is rejected rather than routed. The portable choices across both brokers today are the four intent order types, DAY, and SMART routing. Everything else is broker-specific. GOOD_TILL_CANCEL, IMMEDIATE_OR_CANCEL, and the auction instructions are Alpaca only. The direct exchange routes are Lightspeed only. So the work is a review, not a rewrite: read your intents for values outside that portable set, and decide what the second broker should do instead. The matrices are in Supported Order Types, Supported Time In Force, and Supported Destinations.

​

A realistic rollout plan

Here is how this looks in practice. Start where you already are, with your strategy running against your first broker. Add the second broker in your config and point it at paper trading first, since Anthid’s free tier includes paper trading with no credit card and no sales call. Run the same strategy against both brokers side by side for a few sessions and compare fills, latency, and behavior in the normalized event stream. When you trust what you see, flip the second broker to live. Total code changes along the way: none. Compare that to the custom route, where the same rollout starts with a month of adapter work before you can even begin testing.

​

The bigger point

Broker choice should be a business decision, not an engineering project. Maybe you want better fills, redundancy during outages, or an asset class your first broker does not cover. Those are good reasons to add a broker, and none of them deserve a quarter of engineering time. With one API in front and your brokers behind it, the decision shrinks to the size it always should have been: a line of configuration.