Why were my Binance Futures stop orders failing with error -4120?

On December 9, 2025, Binance retired stop-type orders on its classic futures endpoint and moved them to its Algo Order service. Orders sent the old way come back with -4120. Plain market and limit entries were untouched, which is why the same alert could open a position but fail to place its stop.

Do I need to change my commands after the Binance fix?

No. Autoview now routes every stop-type order on Binance Futures through the Algo Order service, for both USDT-margined and COIN-margined contracts. Your stop loss, take profit, trailing stop, and conditional entry commands read exactly as they did before.

How do I get the Binance Futures fix?

Update the Autoview extension from the Chrome Web Store, though Chrome usually updates it on its own within a few days. The server-side webhook execution carries the same fix. Then fire a test stop at a demo or testnet connection and watch it land.

Binance returned a 503 'unknown execution status' error. Did my order go through?

Maybe. A 503 with that message means Binance itself does not know the outcome, not that the order failed. It may have been placed. Check the order's actual status on Binance before resubmitting it or its cancel, since retrying blind risks a duplicate order.

Stop Orders on Binance Futures Are Fixed

Autoview

This is a dated compatibility note, tied to Binance's December 9, 2025 migration, not a permanent guarantee about how Binance's Algo Order service will behave going forward. If your stop loss, take profit, or trailing stop orders on Binance Futures started failing around that migration while plain entries kept working, it was not your alert syntax. Binance changed how stop orders are placed. Autoview's Binance Futures and Binance Delivery integrations route conditional order types through Binance's Algo Order service to match, and your existing commands read the same way they did before the migration. Binance can change this endpoint again; if your stops start failing after a future Binance release, treat that as a new compatibility question, not a contradiction of this page.

What Binance changed

On December 9, 2025, Binance retired stop-type orders on its classic futures order endpoint. A STOP, STOP_MARKET, TAKE_PROFIT, or TRAILING_STOP_MARKET order sent the old way now comes back with error -4120 and a message telling you to use the Algo service. Market and limit entries were untouched. That split made the breakage genuinely confusing: the same alert that opened your position fine would fail the moment it tried to place the protective stop.

What we did

Autoview routes every stop-type order on Binance Futures through Binance's Algo Order service (`sources/integrations/integration/binance/BinanceFutures.js:46-68`, `routeBinanceConditionalOrder`, sending STOP, STOP_MARKET, TAKE_PROFIT, and TRAILING_STOP_MARKET types to `/fapi/v1/algoOrder` with `algoType=CONDITIONAL`). This covers both USDT-margined and COIN-margined contracts (COIN-M's equivalent surface on `/dapi` lives in `BinanceDelivery.js`). Cancelling and listing carried over too: cancels for an algo order route to `DELETE /fapi/v1/algoOrder` by `algoId`, and open orders are read back from `/fapi/v1/openAlgoOrders` and normalized to look like a classic order, so a cancel or list command finds and clears an algo stop the same way it always handled the classic kind.

Nothing changes on your side. Stop loss, take profit, trailing stop, and conditional entry commands read exactly as they did before. The routing happens inside the integration, where it belongs.

One Binance-side behavior to know about regardless of which order type you send: Binance's API can return an HTTP 503 with an "unknown execution status" message when it genuinely does not know whether your order went through. That is not the same as a failure. The order may have actually been placed on Binance's side even though the response looks like an error. Before resubmitting a stop, entry, or cancel that came back with a 503, check the order's actual status on Binance (via the API or the exchange UI) rather than assuming it failed and firing it again; retrying blind risks placing the same order twice.

Other fixes shipping with it

The same release repairs a cluster of order-handling problems we found while verifying exchange behavior command by command.

Bybit spot: a stop or conditional order used to be accepted by the exchange and quietly stored with no trigger armed. It looked placed. It never fired. Autoview now sends the order filter Bybit requires, so a spot stop rests on the exchange as a real trigger order you can see.
OANDA: fill-or-kill (t=fok) and immediate-or-cancel (t=ioc) orders now work. And an order OANDA creates then immediately cancels, like a guaranteed stop priced too tight, now reports the cancellation reason instead of reading as a success.
Crypto.com: OCO orders place both legs correctly.
Time in force: a new tif= parameter sets time in force explicitly on exchanges that support it, and the Syntax Builder has a matching field. An unsupported value throws a clear error rather than guessing.

The Bybit one was the worst of these. An error you can read beats an order that pretends to exist.

What you need to do

Update the Autoview extension from the Chrome Web Store. Chrome usually updates extensions on its own within a few days, so you may already have it. Autoview's server-side webhook execution carries the same fixes.

Then test your stops. Fire an alert at a demo or testnet connection and watch the stop order land on the exchange. Several demo connections are free, so the test costs nothing.

Found something still misbehaving?

Tell us. We rebuilt our exchange verification this year around placing real orders and reading them back, and reports from live traders are how the remaining gaps get found. Write to support@autoview.com with the exchange, the command, and what you expected.

See supported platforms