What is an API broker?
An API broker is a financial services provider (or a service layer) that lets you place and manage orders through an application programming interface (API) instead of a web terminal. In practice, the API sends order requests, the provider (or an upstream execution venue) processes them, and execution results are returned to your system.
A key point is to separate mechanics (how orders are submitted, modified, and acknowledged) from market- and provider-dependent variables (prices, liquidity, execution timing, and costs). Many misunderstandings happen when these two are treated as the same thing.
Common misunderstandings and their consequences
1) Confusing “API access” with “automatic best execution”
A mistake is treating the presence of an API as proof that execution will be optimal or predictable. The API often changes how orders are sent, not the underlying reality that fills depend on market conditions and how the broker routes orders.
Consequence: you may expect smoother outcomes than what the environment can deliver, then be surprised when fills differ from your mental model.
Neutral check: confirm what the API and documentation actually promise about order acknowledgements versus execution results. If the system returns an “acknowledged” status that is not the same as “filled,” treat them as different events.
2) Assuming “one price” means the final executed price
Another common error is assuming that a single quote, screen price, or “last seen” number equals the eventual fill price. Execution involves timing, order type rules, and available liquidity.
Consequence: your calculations may be off because the number you used was only an input estimate, not the final outcome.
Assumptions to state in any example: define the time you read the reference price, the expected fee model, and the order type (for example, whether the order is market-like or limit-like). Without that, comparisons are not meaningful.
3) Ignoring latency and system timing
Even without real-time data assumptions, there is a general mechanics issue: time matters. Network delay, queueing, and processing time can affect whether your order meets the conditions you thought it would.
Consequence: you may see partial fills, delayed fills, or behavior that seems inconsistent with your inputs.
Neutral check: measure end-to-end timestamps you control (API request time, response time, and execution event time). If the system provides event identifiers, reconcile them in order.
4) Underestimating costs and fee impacts
Some people focus on price movements and overlook costs such as commissions and spreads/markups embedded in execution. With API trading, the reported price and the total cost can be separated by fees.
Consequence: profitability or break-even assumptions fail because the total cost basis is higher than expected.
Neutral check: verify how the platform reports fees, where they appear in statements, and how they relate to each execution. Reconcile your internal trade record to the provider’s execution summary.
5) Misunderstanding order states and reconciliation
APIs typically have multiple states: request accepted, pending, partially filled, filled, cancelled, rejected, or expired. A frequent mistake is reading only the newest state and missing the earlier lifecycle.
Consequence: logs and your portfolio view can diverge, leading to incorrect monitoring, incorrect risk checks, and confusion about what actually happened.
Neutral check: use an order lifecycle checklist: (a) was it accepted, (b) was it acknowledged, (c) did it execute partially or fully, (d) were modifications applied, and (e) did it end in a terminal state. Compare your internal records to the provider’s event log.
Limitations and risks to keep in mind
Uncertainty is part of the mechanics. Outcomes vary with market conditions, execution timing, and total costs, and historical relationships do not guarantee future results. That means you should avoid treating backtests, sample outputs, or “happy path” behavior as proof of consistent results.
At least one material failure mode to watch for is reconciliation gaps: when your system assumes an order was filled, but the provider reports a different terminal state (for example, rejected, cancelled, or only partially filled). Another is parameter mismatch: sending order attributes (size, side, order type, time-in-force) that differ from what you intended.
Verification or next question: how to check facts without assumptions
A neutral way to verify what an API broker actually does is to rely on documentation and controlled, small tests.