Retail platform automation has three shapes. You can write an expert advisor and run it inside the terminal. You can fire alerts from a charting tool into a webhook and have something downstream place the order. Or you can talk to the broker's API directly, from your own process, with your own code.
The third option used to be reserved for institutions with a FIX connection and a compliance department. It is now common enough that a good number of retail brokers publish REST and WebSocket endpoints, hand out API keys from the client portal, and document them publicly. The question is no longer whether you can, but whether you should.
What a trading API actually exposes
Nearly every retail trading API breaks into the same four surfaces, regardless of the broker.
Account and instrument data: balance, equity, margin, open positions, the tradable symbol list with its contract size, tick size and trading hours. This is read only and cheap to poll.
Market data: quotes, and sometimes candles and depth. This is where REST and streaming diverge sharply. A REST call gives you a snapshot at the moment you asked. A WebSocket subscription pushes every tick as it happens. For anything reacting to price inside a minute, polling is the wrong tool, and the rate limits will tell you so quickly.
Order management: place, modify, cancel, close. The important detail here is not the endpoint but the response. A good API returns a broker order identifier immediately and a separate execution message when the fill happens, with the filled price. A weak one returns a bare success and leaves you to poll for what actually occurred.
History: closed trades, deals, ledger entries. Under-used and the most valuable surface for anyone building a real trading journal, because it is the only feed that reconciles what you intended with what the broker booked.
Authentication, and the part people get wrong
Most retail APIs use one of two schemes. A long lived API key and secret, sent with each request. Or a login call that exchanges credentials for a short lived token which you refresh. Some brokers layer a per-key permission model on top, so you can issue a read-only key for a dashboard and a trading key for the strategy.
Use that separation if it exists. A read-only key on your monitoring dashboard means a leaked laptop is an information problem, not a trading problem. And never put a trading key in a browser page, a public repository or a chat message. The key is your account.
Test everything on a demo account first, and keep testing there after you go live. A demo key and a live key should be a single config value in your code, never a code change, because the day you have to switch fast is the day you will fat-finger the edit.
Rate limits and idempotency
Two things break naive API clients. The first is rate limiting: a cap on requests per second or per minute, sometimes separate caps for market data and order actions. Hitting it returns an error, and code that retries immediately in a loop makes it worse. Back off, and cache anything static like the symbol list.
The second is the duplicate order. Your request times out. You do not know whether the order was placed. You retry, and now you have two positions. The defence is a client order identifier, a unique string you generate and attach to the request, which the broker uses to reject a repeat. If your broker's API supports one, use it from day one. If it does not, query open orders before retrying, always, without exception.
API, expert advisor, or webhook
The honest comparison comes down to what you need around the strategy rather than the strategy itself.
An expert advisor wins on speed of development for a single-instrument, single-logic system, and it runs where the platform runs. It loses when you want to store state, run several accounts, or debug without a chart open. It also ties you to one platform and a running terminal, which is why so many people end up renting a VPS just to keep it alive.
Webhooks from a charting tool are excellent when the signal logic belongs on the chart and you only need execution downstream. The weakness is the return path: the chart does not know the fill price, the slippage or whether the order was rejected for margin. If that matters, the API is the only surface that tells you.
Direct API is right when the strategy needs a database, when you run several accounts, when you want your own risk layer sitting between the signal and the order, or when the language you think in is not the platform's scripting language. Modern web-first platforms make this easier because the client application already talks to a documented backend, which is the model eTrader is built on.
The risk layer nobody writes until it is too late
Code places orders faster than a person can cancel them. Before any automated client goes live, build three guards outside the strategy logic: a maximum position count, a maximum daily loss that flattens and stops the process, and a kill switch you can trigger from your phone. A bug in strategy code with no guard around it is how small accounts become empty ones. Position sizing rules are not enough on their own when the thing sending orders is a loop.
Trading with leverage carries a high risk of loss, and automating it removes the pause where a human would have hesitated. That pause was doing more work than most people credit.
"If your strategy is one indicator and a stop, an EA is fine. The moment you need a database, a dashboard and a phone alert, keeping it inside a chart window becomes the hard way to do it."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- A retail trading API exposes four surfaces: account state, market data, order management and history, and the history feed is the most under-used of the four.
- Use streaming for anything reacting inside a minute. Polling a REST quote endpoint hits rate limits and gives stale prices.
- Attach a client order identifier to every order so a timeout and retry cannot open a duplicate position.
- Build the maximum position count, daily loss cut-off and kill switch before the strategy goes live, not after the first incident.
Frequently Asked Questions
Do I need a special account to use a broker API?
Often no. Many brokers issue API keys from the ordinary client portal, sometimes after enabling a setting or agreeing to extra terms. Some restrict access to certain account types or require a request, and a few offer FIX only above a volume threshold.
Is an API faster than an expert advisor?
Not necessarily. Execution speed is dominated by the distance to the broker's servers and by the broker's own processing, not by the client language. The real advantage of an API is control, observability and running outside a terminal, rather than raw latency.
What happens if my API client crashes with positions open?
The positions stay open. The broker does not know your process died, and stops or take profits set on the server side remain, while any logic held only in your code does not. Server-side protective orders are the reason to place stops with the order rather than manage them in memory.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.