USDS Futures SDK new_order() lacks conditional order params while docs/test_order expose them

[pe8]

SDK package/version

• binance-sdk-derivatives-trading-usds-futures==11.0.0 (latest on PyPI at the time of checking)
• binance-common==4.0.0
• Python 3.11

Problem

DerivativesTradingUsdsFutures.rest_api.new_order() does not expose typed parameters for conditional/close-all order fields such as stop_price, close_position, activation_price, callback_rate, working_type, and price_protect.

This is inconsistent with test_order(), which does expose those parameters, and it is easy for users to assume a validated test_order() call can be promoted to new_order() with the same keyword arguments.

In addition, the USD-M Futures docs now say conditional orders are migrated to Algo Service. The SDK does expose new_algo_order() with trigger_price, close_position, and client_algo_id, so perhaps the intended behavior is to route users to new_algo_order() instead of new_order() for STOP_MARKET / TAKE_PROFIT_MARKET. If so, it would be helpful for the typed SDK surface or docs to make that explicit.

Reproduction

import inspect
import importlib.metadata as md
from binance_common.configuration import ConfigurationRestAPI
from binance_sdk_derivatives_trading_usds_futures.derivatives_trading_usds_futures import DerivativesTradingUsdsFutures

client = DerivativesTradingUsdsFutures(
    config_rest_api=ConfigurationRestAPI(api_key="k", api_secret="s")
)

print(md.version("binance-sdk-derivatives-trading-usds-futures"))
print(md.version("binance-common"))
print(inspect.signature(client.rest_api.new_order))
print(inspect.signature(client.rest_api.test_order))
print(inspect.signature(client.rest_api.new_algo_order))

Observed with SDK 11.0.0:

new_order(symbol, side, type, position_side=None, time_in_force=None, quantity=None,
          reduce_only=None, price=None, new_client_order_id=None,
          new_order_resp_type=None, price_match=None,
          self_trade_prevention_mode=None, good_till_date=None, recv_window=None)

# no stop_price / close_position / activation_price / callback_rate / working_type / price_protect

test_order(..., stop_price=None, close_position=None, activation_price=None,
           callback_rate=None, working_type=None, price_protect=None, ...)

new_algo_order(..., trigger_price=None, close_position=None, price_protect=None,
               client_algo_id=None, ...)

Why this matters

For risk-management orders on USD-M Futures, users commonly need close-all stop loss / take profit orders (STOP_MARKET or TAKE_PROFIT_MARKET with close-position semantics). With the current typed new_order() method, these fields cannot be passed directly even though test_order() accepts them.

After the conditional-order migration, using /fapi/v1/order for these order types may return -4120 STOP_ORDER_SWITCH_ALGO, and the working implementation is to use new_algo_order(algo_type="CONDITIONAL", type="STOP_MARKET"/"TAKE_PROFIT_MARKET", trigger_price=..., close_position="true", client_algo_id=...).

Relevant official docs

• Test New Order docs list stopPrice, closePosition, activationPrice, callbackRate, workingType, and priceProtect: https://developers.binance.com/docs/derivatives/usds-margined-futures/trade/rest-api/New-Order-Test
• New Algo Order docs say this endpoint is used to place TP/SL and trailing stop orders, and list triggerPrice and closePosition: https://developers.binance.com/docs/derivatives/usds-margined-futures/trade/rest-api/New-Algo-Order
• Derivatives change log says USD-M conditional orders migrated to Algo Service and /fapi/v1/order / /fapi/v1/batchOrders will block affected order types with -4120 STOP_ORDER_SWITCH_ALGO: https://developers.binance.com/docs/derivatives/change-log#2025-11-06
• New Order response example still includes stopPrice and closePosition: https://developers.binance.com/docs/derivatives/usds-margined-futures/trade/rest-api

Suggested fix / clarification

One of the following would remove the ambiguity:

1. Add the missing typed parameters to new_order() if /fapi/v1/order is still intended to support any of these fields.
2. If conditional orders must use Algo Service now, document this clearly in the SDK docs / generated method docs and possibly raise a clearer client-side error or warning for affected new_order(type=...) values.
3. Keep test_order() and new_order() parameter surfaces consistent, or explicitly explain why test_order() accepts fields that new_order() intentionally does not.

[alplabin]

Hello @pe8,

Thanks for your message.

As mentioned in the Changelog of November 6th, 2025, new endpoints were created to support new conditional order types (e.g. STOP_MARKET, TAKE_PROFIT...), including the POST fapi/v1/algoOrder endpoint, which are the only endpoints supporting them. Therefore, some specific parameters related to these conditional order types are only available in these endpoints (e.g. activatePrice, closePosition...) and not in the POST /fapi/v1/order endpoint as it uses other order types.

If you want to implement stop loss or take profit strategies using the POST /fapi/v1/order endpoint, please refer to this post.

This SDK only reflects what is documented in the official documentation, and no decisions regarding endpoint configuration are made at the SDK level.