The journey in six steps
- Origin: a person clicks a button or a rule emits a signal.
- Validation: the system checks the instrument, account, permissions, size, and active rules.
- Order construction: it defines the contract, side, quantity, order type, and price when applicable.
- Submission: it sends the instruction to the broker and stores a reference for tracking.
- Response: the API may accept or reject the request. “Accepted” still does not mean “filled.”
- Reconciliation: the final broker state is compared with the position and history.
In an automated workflow, every step needs a visible state. “Signal received” is not evidence that anything was bought or sold.
Order type changes the possible outcome
A market order seeks execution, but its price can vary. A limit order sets a price boundary and may remain unfilled. A stop order triggers another order after a specified price is reached; its execution price can differ. Available types and policies depend on the broker and instrument.
Record the displayed quote, submitted limit if any, order status, and price of each fill. Without that sequence, stale market data and execution slippage can look identical in a final report even though they have different causes.
Three failure cases to test deliberately
- Duplicates: a retried alert should not accidentally open two positions. Check identifiers and replay behavior.
- Expired connection: see what a person is told when authorization expires or the API stops responding.
- Partial state: test cancellations and partial fills. Open quantity and exit instructions must reflect the actual position.
A good test ends by reading the broker’s state, not merely the app’s message. If they disagree, investigate before sending more instructions.