> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anthid.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How to add a second broker without a rewrite

> Why the second broker breaks custom stacks, what carries across when the brokers sit behind one API, and a rollout plan that costs no code changes

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](/pages/concepts/intents), and Anthid handles retries, failures, reconciliation, and each broker's quirks for you. [Alpaca](/pages/brokers/alpaca) and [Lightspeed](/pages/brokers/lightspeed-connect) are connected today, with [more on the roadmap](/pages/community/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](/api-reference/ledger/overview) 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.

<Warning>
  Maximum daily loss and maximum position size can be configured today, but they are stored rather than enforced: the pre-trade evaluation checks order size alone. Keep those checks in your own application until [Controls Overview](/pages/controls/overview) says otherwise.
</Warning>

## 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](/pages/brokers/supported-order-types), [Supported Time In Force](/pages/brokers/supported-time-in-force), and [Supported Destinations](/pages/brokers/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.

<Note>
  Live broker accounts need a Starter or Professional plan, and your tier also caps how many broker connections an organization can create. See [Availability](/api-reference/accounts/overview#availability).
</Note>

## 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.

<Card title="Trading accounts" icon="layer-group" href="/api-reference/accounts/overview" horizontal>
  How a connected broker account is represented, and how credentials are stored.
</Card>