MngRestoreTrade

Description: Allows a manager to reopen a closed trade order by its order ID.

This method follows the common Trade Request Lifecycle. A successful response means the restore request was accepted into runtime processing.

Warning

This method is available only to manager, admin, and dealer sessions, and only restores closed market trades.

Access Control

Requires del_trades for manager/dealer sessions. The target account must also match the manager groups and brand scope loaded from the cached manager record. Token payload is used only for manager id and session type.

Request Parameters

Name	Type	Required	Description
order	int	Yes	ID of the closed trade order to restore
charge_missed_swaps	bool	No	If true, preserves the existing last_swap_time so missed swaps can be charged on the next rollover. If omitted or false, resets last_swap_time to the restore time so swaps are not charged for the closed period.
__access	object	Yes	Access object containing manager, admin, or dealer session information

Request Example

{
  "order": 1001234,
  "charge_missed_swaps": false,
  "__access": {
    "type": 3
  }
}

Response Semantics

If the request is accepted:

• the restore request passed validation
• the order was accepted into runtime processing
• final restore application is resolved asynchronously
• if charge_missed_swaps is omitted or false, the swap checkpoint is reset to the restore time
• if charge_missed_swaps is true, the previous swap checkpoint is preserved

The response should be treated as an acknowledgment object.

Response Parameters

Name	Type	Description
accepted	bool	Always true on successful acknowledgment
order	int	Order identifier being restored
state	int	Accepted request state, typically TS_RESTORE_REQUEST

Response Example

{
  "accepted": true,
  "order": 1001234,
  "state": 13
}

Lifecycle Notes

• The immediate response is an acknowledgment, not a final restore report.
• The trade should be tracked by order.
• Final resulting state is resolved later in runtime processing.
• The final restored trade state is expected to become TS_OPEN_RESTORED.
• Swap charging for the period while the trade was closed depends on charge_missed_swaps.

Financial Application

When restore is applied, the historical net result (profit + commission + storage) is reversed from the account balance using the values recorded before restore calculation. The reopened position keeps its entry price and volume; its valuation price (close_price) is the current execution bid for BUY or execution ask for SELL, including applicable spread adjustments. Floating profit is recalculated using the existing currency conversion and account-currency rounding rules before the applied trade event is published. No additional quote is required to reprice the restored position when a conversion rate is available.

Commission and storage contribute to the reopened position's floating net result, and margin is recalculated under the current account/group/symbol rules. Any rollover storage adjustment during restore does not change the historical net amount reversed from balance. If currency conversion is temporarily unavailable, the runtime uses its existing saved-rate fallback; if no rate is available at all, the historical price/profit pair is retained until valuation can resume.

For example, a 0.4-lot BUY with a 100,000-unit contract and entry 1.1002, closed at 1.101 with profit 32, commission -1.25 and storage -0.75, has historical net profit 30. Restoring at execution bid 1.102 reverses 30 from balance and sets floating profit to 72 (floating net 70), not the old profit 32.

A repeated request while the trade is already restored must not apply another balance reversal. The asynchronous admission acknowledgment alone does not prove that restore was applied; reconcile the resulting trade and account state. Closing the restored position realizes its current net result, and a subsequent valid restore reverses that newly recorded historical result.