What “execution quality” for API access means
Execution quality is how well an order placed via an API results in the intended outcome when compared to what you expected at the moment you sent it. In practice, you judge execution quality using observable system behavior: timing, order handling, the correspondence between requested and actual fills, and how often errors or unexpected events occur.
API access changes where execution problems can appear. Instead of only looking at market and strategy behavior, you also consider the “plumbing” around order submission and order lifecycle: how the API receives your request, how it confirms acceptance, how it updates order status, and how it reports trades back to your system.
Core mechanics: what you can measure
To assess execution quality, define a few terms first.
- Request time: when your application sends an order message.
- Acknowledgment/acceptance: when the API confirms the order was accepted for processing.
- Execution event time: when fills or cancels occur (as reported by the API).
- Expected vs. actual outcomes: whether the executed price, quantity, or fill timing matches what your system assumed.
A measurable evaluation usually includes:
- Latency distribution (not just an average). Track the time from request to acknowledgment, and from acknowledgment to first fill. Consider percentiles (for example, how often it is “fast enough”).
- Reliability. Measure rates of rejected orders, timeouts, duplicate requests, and missing status updates.
- Order outcome accuracy. Compare requested price/size/constraints to what was ultimately executed or confirmed (including partial fills).
- Event integrity. Check whether the sequence of order states you receive (accepted → partially filled → filled/canceled) is consistent and complete.
- Cost transparency. Execution quality cannot be separated from total transaction costs (spreads, commissions, fees, and any slippage implied by fill differences). You can only evaluate it using the prices and fees actually applied.
A key idea is to compare your observed execution to a baseline you control. Your baseline can be a controlled test using small orders in consistent conditions, with clearly recorded timestamps and inputs.
Evidence and example: a verification-style test
Assume you run a test where you submit identical limit orders through the API and record:
- the exact request timestamp from your application,
- the timestamp of API acceptance,
- the timestamp of first fill and the full fill,
- executed price and executed quantity,
- any error codes or missing updates.
You then compute a few summaries across many trials:
- Acknowledgment delay = acceptance time − request time.
- Time to first fill = first-fill time − request time (or − acceptance time, as long as you choose one definition).
- Fill deviation = difference between your constraint price and the executed price (directionally and in absolute terms).
- Fill completeness = (filled quantity ÷ requested quantity) for each order, and the share of orders that end partially filled.
Because market conditions can change quickly, you separate two layers of evidence:
- System behavior evidence: whether delays, rejections, and missing updates occur at predictable or stable rates under comparable conditions.
- Market-and-cost evidence: whether fill differences can be explained by changing liquidity and transaction costs rather than by API handling.
You should also keep assumptions explicit. For example, if your test uses the same time-in-force setting or the same order type, note it; otherwise the interpretation of acceptance and partial fills becomes ambiguous.
Limitations and failure modes to account for
Even when measurements look good, execution quality is not fully predictable. Common material limitations include:
- Failure mode: rejected or timed-out orders. A system can be fast when it works, yet still have unacceptable rejection rates when load or connectivity changes. - Failure mode: stale or inconsistent market data. If your application bases decisions on data that lags the moment of order placement, you may see worse fills that are not a “latency” issue alone. - Failure mode: partial fills and post-fill updates. Partial fills can be accurate, but if your application incorrectly tracks remaining quantity or mishandles status sequences, your measured execution “quality” can reflect software logic errors. - Measurement limitation: timestamp alignment. If you compare your local timestamps to API-reported timestamps without understanding clock synchronization, your latency conclusions may be biased. - Evidence limitation: historical does not ensure future.