A cTrader order rejection means the request did not succeed; the useful clue is the specific error returned with it. Capture that response before changing parameters or trying again, because repeating a request without understanding it can create a second problem.
This checklist is for diagnosing a failed cBot trade request. A manual order can fail for broker- or account-specific reasons too, so treat the platform's exact message and your broker's rules as the source of truth.
Start with the result, not the chart
In cTrader Algo, check whether the TradeResult succeeded and inspect its Error when it did not. The platform's ErrorCode reference defines errors such as BadVolume, NoMoney, MarketClosed, Disconnected, InvalidStopLossTakeProfit and NoTradingPermission. The TradeResult.Error reference describes it as the error code for an unsuccessful trade and shows checking it alongside IsSuccessful.
Do not collapse those into “the market rejected my strategy.” They point to different checks: requested size, available funds or margin, session state, connection, permissions, or protective prices. A generic TechnicalError or InvalidRequest is not a diagnosis; preserve the full returned value and surrounding log rather than guessing what it means.
For an Open API integration, use its own model-message and error definitions. Do not assume Algo enum names and Open API error values are interchangeable. They are separate interfaces, even when the human-readable cause sounds similar.
Check the request against this account and symbol
A valid signal is not necessarily a valid order. For a volume-related error, compare the requested units with the symbol's current minimum, maximum and step, then inspect how your code converts lots to units. The cTrader Symbol reference exposes symbol properties; your broker's instrument settings matter more than a value copied from another account.
For NoMoney, check the account and the position already open, then inspect the proposed size and protective levels. The error code tells you the server did not accept the trade for insufficient funds; it does not tell you which input to change, or whether changing it would fit your own risk limits.
For an invalid stop or take-profit, compare the submitted price with the symbol's current quote and the broker's constraints. Avoid automatically moving the level closer or farther just to make the request pass: that changes the trade you intended to place.
Check session and connection before retrying
MarketClosed is a session problem, not evidence that the signal is stale or valid. cTrader's MarketHours.IsOpened() method checks whether the symbol's trading session is active. Session schedules and holidays can vary by instrument and broker, so do not substitute a familiar clock time for the symbol's own schedule.
If the code is Disconnected or a request timed out, first establish whether the platform received a response and whether a position or pending order already exists. A missing acknowledgement is not proof that nothing happened. Reconcile the account state before resubmitting; avoid a blind retry that might duplicate exposure.
That caution is consistent with a broader execution distinction: the SEC explains that market orders do not guarantee an execution price and that a limit order may not execute at all; FINRA describes the order lifecycle as including review and routing before execution. Those are securities-market explanations, not a promise about how a particular CFD broker handles a cTrader request. They do reinforce why “sent,” “accepted,” “filled,” and “filled at the expected price” are different states. See the SEC order-types bulletin and FINRA trade-lifecycle guide.
Keep a rejection record you can reproduce
For each failed attempt, retain:
- Account environment (demo or live), broker, symbol and order side.
- Requested volume and order type, plus the stop/limit prices submitted.
- The exact error code and message,
TradeResult.IsSuccessful, and any order or position identifier returned. - Timestamp with timezone, quote/session context, and the cBot version or code change.
- The account's resulting positions and pending orders before any retry.
This turns “it failed once” into a case you can inspect. If the cause remains unclear, reduce the problem to a controlled demo reproduction and ask the broker with the timestamp and exact error. Do not keep changing several request fields at once; then you will not know which change mattered.
A cBot decision log audit helps connect the signal to the request and response. Before live operation, also use the cTrader symbol preflight checklist. realbacktesting is a trading-software studio for cTrader; its work is built to be checked, not accepted on a claim. Our proof and test-method notes explain how to reproduce the published cBot backtests.
Frequently asked
Does MarketClosed mean my cBot signal is wrong?
No. It identifies a closed session in cTrader's standard error list. Review the symbol's session and the order's timing separately from the signal logic.
Should a cBot retry every rejected order?
Not automatically. First check whether the request was acknowledged and whether an order or position exists; then apply a deliberate retry policy to the specific failure.
Are cTrader error codes identical across Algo and Open API?
No. Read the documentation for the interface you use. The returned code and message for your actual request are more useful than a guessed mapping.