MngDeleteTrade

Description: Allows a manager to permanently delete a closed trade by its order ID. This action is typically used to remove invalid or test trades.

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

Warning

This command only accepts closed market BUY/SELL trades in TS_CLOSED_NORMAL, TS_CLOSED_PART, or TS_CLOSED_BY.

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.

Copy-Follower Manual-Write Checks

For SESSION_USER or SESSION_CUSTOMER requests, this mutation applies the copy-follower manual_trading_mode after the usual account/order ownership checks. The check applies only when the target account has an enabled follower profile. Mode 0 rejects all manual writes; mode 1 permits new or non-copied orders but rejects changes to linked copied orders; mode 2 permits both. Manager/admin/dealer staff sessions bypass this follower policy.

HTTP	Error	Message
403	COPY_MANUAL_TRADING_DISABLED	Manual trading is disabled for this copy follower
403	COPY_COPIED_ORDER_MANUAL_FORBIDDEN	Manual changes to copied orders are disabled for this copy follower

The command returns the denial for its target login or order without accepting that mutation.

Request Parameters

Name	Type	Required	Description
order	int	Yes	The ID of the trade order to delete
__access	object	Yes	Access object with session type info

Request Example

{
  "order": 1001234,
  "__access": {
    "type": 1
  }
}

Response Semantics

If the request is accepted, the server validates the closed market trade and reserves it in TS_DELETE_REQUEST before returning the acknowledgment. Final removal is resolved asynchronously, so the response is not a final delete confirmation. Concurrent or repeated requests cannot both reserve the same closed ticket.

Response Parameters

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

Complete TCP response example

The TCP response envelope contains the request extID, command status, and command result in data:

{
  "extID": "delete-1",
  "status": 200,
  "data": {
    "accepted": true,
    "order": 1001234,
    "state": 8
  }
}

Atomic admission and invalid states

The command checks the live cached trade and changes its state to TS_DELETE_REQUEST while holding the trade-cache lock. That reservation occurs before the success response. A second request for the same ticket, including a concurrent request, sees the reserved state and is rejected; it is not another successful acknowledgment.

For a visible ticket that is no longer in an eligible closed state, the current TCP error response is:

{
  "extID": "delete-duplicate",
  "status": 400,
  "data": {
    "error": "RET_TRADE_INCORRECT_STATE",
    "message": "Unknown error"
  }
}

RET_TRADE_INCORRECT_STATE is returned for a non-closed/non-market trade or a ticket already reserved for deletion. The handler currently formats this return code's human-readable message as Unknown error. Validation and access failures can be returned before the trade-state check. After an accepted response, track order through trade events or a follow-up trade query to observe final removal.