A broker API is a software interface for submitting orders and reading account or market data.
That definition hides the operational differences that matter to an unattended agent. One API may return an order ID before the venue has accepted the order. Another may deliver fills over a stream that disconnects without replay.
A third may offer broad market access but translate broker-specific order types into a smaller common set. Choosing an approach means comparing failure handling and execution semantics, not just counting endpoints.
Compare the four integration approaches
Direct broker API
A native API connects the agent to one broker's own order and account services. It usually exposes the broker's actual order types, time-in-force options, asset rules and rejection reasons. That specificity is useful for a strategy that depends on features such as bracket orders, fractional quantities or venue-specific routing.
The cost is integration work. Each broker can represent order states differently, use different symbols and session calendars, and impose its own request limits. An agent trading across two brokers may need separate adapters and separate reconciliation logic. Direct access is usually the clearest choice when one broker is central to the strategy and its API exposes all required order and account events.
Multi-broker aggregator
An aggregator provides one interface across multiple brokers. It can reduce the work of authentication, symbol mapping and basic order submission. That is useful for prototypes, multi-broker portfolios or systems that need a fallback connection.
The common interface is also a layer of abstraction. It may omit a broker-specific order instruction, normalise distinct rejection states into one error, or expose data later than the broker's own stream. Confirm whether the aggregator forwards client order IDs, supports cancel-replace, reports partial fills individually and gives access to the original broker response. A shared API is not necessarily a shared execution model.
FIX connection
FIX is a message protocol used for electronic trading, often with persistent sessions and explicit sequence numbers. A FIX connection can suit firms that need predictable session handling, richer order workflows or high message throughput. It also gives the integrator more responsibility for session configuration, message validation, sequence recovery and operational monitoring.
FIX access often involves commercial, technical and onboarding requirements that are disproportionate for a small account. Connectivity may depend on a broker's supported FIX profile, network setup and permissions.
It is not automatically lower latency or more reliable than a broker's REST and streaming APIs. Benchmark the specific connection and support model rather than treating the protocol name as a performance guarantee.
Browser automation
Automating a web trading interface can appear to be the fastest route when no API is available. It is fragile for unattended execution. A layout change, expired session, pop-up or delayed page update can break the sequence between checking an order and submitting it. Browser automation also makes it harder to prove which state the agent observed before acting. Use it for manual workflow support or controlled testing, not as the default production order channel.
Match the interface to the operating load
The table gives typical market ranges for common integration patterns. They are planning estimates, not audited results for any named provider. Actual limits and timings vary with asset class, account tier, network path, market conditions and whether the figure measures acknowledgement, fill or data delivery.
| Approach | Typical request or message rate | Typical acknowledgement latency | Integration and recovery burden |
|---|---|---|---|
| Direct REST plus stream | About 2-20 requests per second per account, sometimes lower | About 50-500 ms for an API response | Medium; reconnect and reconcile using broker records |
| Multi-broker aggregator | About 1-10 requests per second per account | About 100-800 ms, including the extra service hop | Low to medium; verify broker-specific feature gaps |
| FIX session | About 10-1,000 messages per second, depending on setup | About 1-100 ms on a configured network path | High; manage session state, sequences and replay |
| Browser automation | Typically one action every 1-5 seconds | About 1-10 seconds, with wide variation | High; detect page changes and confirm every state transition |
These figures are not interchangeable measures. A fast API acknowledgement says the request reached an API component. It does not prove the order reached an exchange, received a fill or is visible in a later account snapshot. Likewise, a request limit may apply per IP address, account, endpoint or rolling time window. Read the current broker terms and measure under the permissions and account configuration the agent will actually use.
Build around order state, not responses
Model an order as a sequence of events, not a single successful call. A typical lifecycle can include pending submission, accepted, partially filled, filled, cancel pending, cancelled, rejected or expired. The broker may send events out of order, repeat them after reconnect, or update a cumulative filled quantity without providing every intermediate message.
Persist a client-generated order ID before sending a request. If the connection times out, do not blindly resubmit the same intent with a new ID. Query open orders or search by the original ID first.
Where the broker supports idempotency keys, check their scope and expiry. Idempotency is only useful if retries with the same key cannot create a second live order.
For each order, retain at least:
- Client and broker order IDs, instrument, side, quantity, price and time-in-force.
- Submission time, acknowledgement, each fill, fees where available, and final status.
- The raw broker event or response, alongside the agent's normalised interpretation.
- A revision or sequence value that lets the system detect stale updates.
On reconnect, fetch the broker's current open orders, recent executions, positions and cash balances. Compare them with the local ledger before allowing new risk. A stream is a low-latency notification path, not a durable source of truth unless the broker explicitly provides replay with a documented retention window.
Measure the limits that shape behaviour
A useful adapter should expose more than the happy path. Test the smallest supported quantity, price increments, market-hours rules, order expiry, short-sale permissions, and behaviour around partial fills. Record which errors are retryable. A rejection for an invalid tick size needs a corrected order, not an automatic retry; a transient gateway error may merit a bounded retry after checking order status.
Rate limits change agent design. If an account allows only a few requests per second, polling every order and position independently can exhaust the budget. Prefer streams for updates, batch queries where available, and reserve capacity for cancels. Use backoff with jitter after throttling, but put a strict ceiling on delay for risk-reducing actions. A cancel request that waits behind market-data polling is a scheduling failure.
Choose by failure mode and control requirements
For a single-broker strategy, direct access often offers the best visibility into native order rules. For a system that needs several brokers and modest customisation, an aggregator can shorten the first integration, provided it exposes enough raw detail for recovery. FIX is worth evaluating when message volume, session control or institutional connectivity justifies the operational work. Browser automation has the weakest guarantees for unattended order handling.
Before selecting a route, make a small acceptance test that exercises normal and adverse cases:
- Submit a limit order and verify the response, broker order record and local order state agree.
- Partially fill the order, disconnect the stream, reconnect, and reconcile executions and remaining quantity.
- Cancel during a fill and confirm whether the cancel acknowledgement includes the final filled amount.
- Send an invalid quantity or price and verify the agent classifies the rejection without retrying it unchanged.
- Throttle or interrupt requests, then prove the agent avoids duplicate exposure while restoring its view.
Keep a durable audit trail for decisions and broker messages. Track acknowledgement latency, fill latency, rejection rate, disconnect duration, reconciliation differences and requests per limit window.
Separate these measures by instrument and session. Typical latency can change sharply between liquid hours and an opening auction, and a platform's overall average can conceal the tail that causes an agent to duplicate or miss an order.
For a structured way to compare platform access, the FX-Tech trading platform index can help frame questions about API availability and agent suitability. Treat any directory or score as a starting point, then verify current documentation, permissions, rate limits and behaviour in the account environment.
Make the choice conditional
The strongest interface is the one whose semantics the agent can observe and recover from. An API with more order types is not automatically better if it hides partial fills. A common aggregator schema is not a guarantee that every broker behaves alike. FIX's session controls do not remove the need to reconcile account state. The adapter should preserve raw messages, normalise only what the strategy needs, and fail closed when its view of exposure is uncertain.
Do not choose from a feature list alone. Compare the operational cost of maintaining adapters, the quality of status and execution events, and the time needed to restore a trusted state after a disconnect. For unattended trading, the recovery path is part of the interface.
This advice does not apply to a system that only generates signals for a human to review and submit manually. In that case, a stable read-only feed and clear signal records may be sufficient, and the cost of an order-capable integration may not be justified.
Frequently Asked Questions
What should a broker API support for an autonomous trading agent?
It should support order submission and cancellation, reliable order and execution status, account and position queries, and a way to recover state after a disconnect. Client order IDs and clear error responses help prevent duplicate orders.
Is a direct broker API better than an aggregator?
A direct API usually exposes more broker-specific order behaviour and response detail. An aggregator can reduce integration work across brokers, but developers should check for missing order types, normalised errors and delayed event delivery.
How should an agent handle a timed-out order request?
It should check the order using the original client ID or query open orders before submitting again. A timeout does not prove that the broker failed to receive the request, so retrying with a new ID can create duplicate exposure.
Does FIX always provide lower latency than REST?
No. FIX can support persistent sessions and high message throughput, but performance depends on the broker, network path and configuration. Measure acknowledgement and fill timings for the specific connection and workload.
Should an unattended agent use browser automation to place orders?
Usually not. Interface changes, session expiry and delayed page updates make browser-driven execution hard to observe and recover. It may suit supervised workflows or testing, but an order API is a stronger default for production execution.
