Forex orders and position stops

These six endpoints are default OFF and unverified against a live backend. Reads require acc:read; writes require trade:real. Account restrictions always apply, and a nonempty market allowlist must include FX. Writes also require the independent FUTU_FOREX_ORDER_WRITES switch and the existing experimental/trading switches.

REST POST	MCP	CLI
/api/get-forex-orders	futu_get_forex_orders	get-forex-orders
/api/get-forex-order-detail	futu_get_forex_order_detail	get-forex-order-detail
/api/cancel-forex-order	futu_cancel_forex_order	cancel-forex-order
/api/set-forex-position-stops	futu_set_forex_position_stops	set-forex-position-stops
/api/confirm-forex-order	futu_confirm_forex_order	confirm-forex-order
/api/modify-forex-order	futu_modify_forex_order	modify-forex-order

Every request supplies broker_id and the current Forex business account_id. Obtain the account through Forex reads; manage credentials through Forex unlock. No request accepts a cipher, opaque internal request or ROA parameter.

Reads

Order-list view defaults to today; accepted values are today, open, recent_three_days, recent and history. Optional paging fields are page_flag and page_size.

Non-history views may use top-level time_begin_us, time_end_us and side, but cannot supply history_filter. History requests put filters inside history_filter and cannot supply those three top-level fields.

History-filter fields are symbol, currencies, destinations, order_types, trade_types, order_status, sides, for_trigger, show_related_order, related_group_types, time_begin_us, time_end_us, date_begin, date_end, query_word and sort_rule. Times use microseconds; dates use YYYYMMDD. Zero is a meaningful destination/trigger filter value.

Order detail additionally requires order_id and optionally accepts exchange. Read results do not prove that an earlier unknown mutation succeeded.

Mutations

Cancel requires order_id and idempotency_key. Quick price modification requires order_id, current order_version, new_price and idempotency_key. Only eligible Limit/StopLimit orders are supported; original quantity and trigger context remain unchanged.

Position stops require position_id, currency, selection, idempotency_key and quote_options. All three quote booleans—before, after, overnight—must be explicit; false is valid. The position filters exclude_zero_positions, use_option_combo and exclude_delisted must also be explicit. Selection is unset, take_profit, stop_loss or both; only selected price fields may be supplied, and selected prices must be positive and nonzero. Both validates the relationship against the original position direction; equality is allowed.

Optional pdt_protection expresses the PDT protection choice. When applicable to the target account, a missing choice prevents submission rather than disabling protection.

New price inputs use plain decimal strings with at most 35 significant digits, excluding leading/trailing zeros from the count. Integer trailing zeros remain in the output. Signs, exponent notation, whitespace and NaN are not supported. Inputs exceeding the bound are rejected rather than rounded to 35 digits. Original backend quantities and existing stop fields are not subject to this new-input bound.

Quick price modification only normalizes leading/fractional trailing zeros. Position stops apply the current effective price range and precision rules. These endpoints do not expose new orders, quantity modification or market position closing.

Confirmation and unknown outcomes

Confirmation requires confirmation_id and nonempty selections, each containing the returned order_id and explicitly approved confirm_types. For position-stop confirmation, the returned order_id may be empty: explicitly copy that empty string, never invent an order ID or omit the field. Duplicate selections are rejected, and types must match the original confirmation requirement. It is limited to the current caller's pending operation; opaque internal confirmation payloads are not public inputs.

Mutation result contains intent_key, attempt_id, state and optional confirmation information, message and need_op_confirm. confirmation_prompts preserves each original title, content, button text and text ID for review before explicit confirmation. Inspect the state: a response is not proof of completion or execution. Unknown/timeout writes are not automatically retried. Query the original operation using GetTradeIntent; matching position values alone are not causal evidence.

MCP uses configured OpenD REST forwarding. CLI uses --rest-url, --api-key and --c2s-json to preserve the actual caller. Gateway and gRPC use the corresponding public protobuf contracts and the same business/permission checks.