Binance API error -2011: CANCEL_REJECTED, Unknown order sent

Binance error -2011 is CANCEL_REJECTED. Its official message is just “CANCEL_REJECTED”; the reason is in msg, and it is usually “Unknown order sent.” — documented as the order “could not be found”.

{ "code": -2011, "msg": "Unknown order sent." }

USDⓈ-M futures documents a longer version that is more honest about what was checked: “Cancel request failure as open order not found in the orderbook: “Unknown order sent”.” Note the words open and in the orderbook. Binance looked for a live order and did not find one. That says nothing about whether the order ever existed, or what happened to it.

What this error actually means

A cancel can only act on an order that is still open. “Unknown order sent.” means there was no open order matching the identifier you gave. That covers very different situations:

• The order filled before your cancel arrived.
• The order was already cancelled or expired.
• The order never existed under that identifier, symbol or account.

The dangerous readings are “the cancel failed, so the order is still live” and “the cancel failed, so nothing happened”. Both are wrong often enough to cost money. The first leads to cancelling again in a loop; the second leads to ignoring a position you now hold. The correct reading is: the state of this order is unknown to you, so go and find out.

-2011 shares its message table with -2010 on Spot, so not every -2011 is “Unknown order sent.” — read the msg. But that message is the one that matters, and the rest of this page is about it.

The usual cause: the order already finished

In practice, the most common -2011 is a race. Your code decided to cancel, and between that decision and the cancel’s arrival, the order filled or expired.

It happens most with:

• Limit orders near the market, which can fill at any moment.
• Orders with an immediate time in force, which by design fill what they can and cancel the rest almost at once — see what is time in force.
• Stop orders that triggered, turning into an execution while you were deciding to pull them.

The consequence is the reason this error matters: you may hold a position you meant to cancel. An order that filled 40% and was then withdrawn, or filled completely before the cancel landed, leaves exposure that your cancel logic believes is gone. The mechanics of partial fills and cancellation are in order lifecycle and partial fills.

Other causes, in order of likelihood

1. You already cancelled it. A cancel timed out, the retry went out, and the first attempt had in fact succeeded. The retry finds nothing open and returns -2011. This is the benign case — but only once you have confirmed the order was cancelled and not filled, because both produce the same message on the retry.

2. The identifier does not match. An exchange order ID passed where a client order ID was expected, or the reverse; an ID from one order used to cancel another. Binance’s description lists the ways an order can be identified — orderId, clOrdId, origClOrdId — and a mix-up between them finds nothing.

3. A reused client order ID. Binance documents newClientOrderId as “a unique id among open orders”, and an ID can be accepted again once the previous order has filled. So a client ID is not a permanent name for one order. If your system reuses IDs, a cancel by client ID can find nothing — or, in principle, target a newer order carrying the same ID. Generate a unique ID per attempt; see what is a client order ID.

4. The wrong symbol, account or environment. In practice a cancel identifies the order together with its symbol, and a mismatch finds nothing. The same applies to a sub-account order cancelled from the master, a testnet order cancelled against production, or a futures order sent to the Spot API.

5. The order was never placed. After an ambiguous placement — a timeout on the create call — code that assumes the order exists and later tries to cancel it gets -2011, because the placement never landed. That is useful information about the placement, and it should have been established by reconciling at the time; see retrying a failed order is not safe.

How to confirm which one you have

Treat -2011 as a trigger for reconciliation, not for another cancel.

1. Query the order by the identifier you used, on the same symbol, account and host.
2. Query open orders for the symbol.
3. Query recent fills covering the window since the order was placed.
4. Query the position or balance.

Then read the result:

What you find	What happened	Next step
Order exists, filled	Race — it executed first	You hold the position; manage it, including its exit
Order exists, cancelled or expired	Already gone	Check filled quantity — it may have partially filled first
Order still open	Your cancel targeted something else	Fix the identifier or symbol and cancel the right order
No trace of the order	Wrong ID, account or environment — or it was never placed	Find where your record of it came from

The general procedure, and why state should come from the venue rather than your own records, is in position reconciliation.

Handling it in code

Do not retry the same cancel. -2011 is a statement about the order’s state. Sending the same cancel again produces the same statement, and a loop of them spends rate limit for nothing.

Do not treat it as success either. A handler that swallows -2011 on the grounds that “the order is gone anyway” misses the filled case, which is the one with money attached.

Log the identifier and the symbol with the error. Most of the diagnosis above depends on knowing exactly what the cancel asked for.

In the classification from error handling patterns for trading APIs, -2011 is a refusal — the exchange understood and said no — but the reason for the refusal leaves your position unknown, which is why it should be handled with the same care as an ambiguous outcome.

FAQ

What does “Unknown order sent” mean on Binance?

It is the usual message behind error -2011, CANCEL_REJECTED: Binance could not find an open order matching the identifier you sent. The order may have filled, been cancelled or expired already, or never existed under that ID, symbol or account. Query the order and your fills before doing anything else.

Does -2011 mean my order is still open?

No — usually the opposite. It means Binance did not find the order open. The most common reason in practice is that it filled or expired before the cancel arrived, which can leave you holding a position you meant to cancel. Check the order’s status and your fills.

Why do I get -2011 when cancelling an order I just placed?

Either it executed immediately — common for orders priced at or through the market, or with an immediate time in force — or the placement never actually succeeded, for example after a timeout. Query the order and recent fills to find out which, rather than assuming either.

Is it safe to ignore Binance error -2011?

Not without checking. In the benign case the order was already cancelled and nothing needs doing. In the common case it filled, and ignoring the error means ignoring a position. Reconcile against the order’s status and your fills, then decide.

Related

• Order lifecycle and partial fills
• Position reconciliation
• Binance API error -2010: NEW_ORDER_REJECTED
• Retrying a failed order is not safe
• Error handling patterns for trading APIs