Skip to content

Learn

Exchange APIs

Binance API error -1013: Filter failure, and how to fix each one

Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs.

Binance Spot error -1013 is INVALID_MESSAGE, documented as “The request is rejected by the API. (i.e. The request didn’t reach the Matching Engine.)” The code tells you almost nothing. The msg tells you exactly which rule you broke.

{ "code": -1013, "msg": "Filter failure: LOT_SIZE" }

Everything after Filter failure: is the name of a per-symbol filter. Read that name, find the field it governs, and you have the fix. This page maps each message to that field. Why filters exist and how to build sizing logic that respects them is in symbol filters and minimum order sizes; this page assumes you already have the error and want to clear it.

What this error actually means

Two things follow from Binance’s own description.

Nothing was placed. The request “didn’t reach the Matching Engine”, so there is no resting order, no partial fill and nothing to reconcile. This is a clean refusal, not an ambiguous outcome — you can correct the request and send it again without first checking what happened.

The rule lives in the symbol’s filters. Every Spot symbol carries its own filter set in GET /api/v3/exchangeInfo. The values are per-symbol, change without notice, and are deliberately not quoted here. Read them from the endpoint, on the same environment you are trading against.

Decoding the message

msgWhat failedField to changeDirection of the fix
“Filter failure: PRICE_FILTER”price too high, too low, or not on the tick sizepriceRound to the tick
“Filter failure: PERCENT_PRICE” / ”…PERCENT_PRICE_BY_SIDE”price too far from the average of previous tradespriceMove it closer to the market; rounding will not help
“Filter failure: LOT_SIZE”quantity too high, too low, or not on the step sizequantityRound down to the step
“Filter failure: MARKET_LOT_SIZE”Same, for MARKET ordersquantity on market ordersCheck the market-order bounds, not the limit ones
“Filter failure: MIN_NOTIONAL”price * quantity too lowSize, or the decision to tradeLarger size, or skip the trade
“Filter failure: NOTIONAL”price * quantity outside minNotional–maxNotionalSizeToo small or too large — check which bound
“Filter failure: MAX_NUM_ORDERS”Too many open orders on the symbolYour open ordersCancel stale ones
“Filter failure: MAX_POSITION”Position (base balance + open BUY quantity) at the limitBalance or open buysNote that resting buy orders count

The list is longer — TRAILING_DELTA, ICEBERG_PARTS, EXCHANGE_MAX_NUM_ORDERS and others — and the full table is on Binance’s Spot error page. The pattern is the same for all of them: the name is the filter, the filter is in exchangeInfo, and the fix is in one field.

Three rows reward a second look.

MARKET_LOT_SIZE is a separate filter from LOT_SIZE. A quantity that is valid for a limit order can fail as a market order. Code that switches order type without re-checking the quantity will meet this.

NOTIONAL has an upper bound as well as a lower one. Most people read any notional failure as “too small”. Check which side you are on before resizing.

MAX_POSITION counts open BUY orders as well as balance. A bot that leaves buy orders resting can hit it without holding much of the asset.

The usual cause

In practice, most -1013 errors come from arithmetic, not intent: a computed quantity that is not a multiple of the step size, or a price that is not a multiple of the tick. Position sizing produces a real number; the exchange accepts only multiples of an increment. Floating-point artefacts make it worse, because the value your logs print may not be the string your client sent.

Two habits remove most of these: round quantity down to the step and price to the tick before submitting, and log the exact string sent, not the parsed number. The position size calculator gives you the risk-derived size; reconciling it with the filters is a separate step that belongs in code.

The next most common in practice is MIN_NOTIONAL or NOTIONAL on a small account, where the correctly sized order is simply below the floor. That is a sizing decision, not a rounding error, and the reasoning for skipping rather than rounding up is in symbol filters and minimum order sizes.

Other causes, in order of likelihood

Filters changed since you cached them. Filters change without notice. A sensible pattern: on a filter failure, refetch exchangeInfo for the symbol once, recompute, and resubmit if the corrected order differs. If it fails again, stop — something other than a stale cache is wrong.

Testnet values used against production. The filters you tested against belong to the environment you tested in. Production’s exchangeInfo is the one that counts; see Binance testnet API keys.

Orphaned orders. MAX_NUM_ORDERS usually means a strategy that places orders faster than it cancels them. Count open orders before blaming the filter.

Prices set far from the market. PERCENT_PRICE catches limit and conditional prices placed a long way from recent trades — during a fast move the reference lags, so an order that looked reasonable can fall outside the band.

Futures does not use this message

This is the difference that catches people moving from Spot to USDⓈ-M futures.

On the futures error page, -1013 is INVALID_MESSAGE with the message “INVALID_MESSAGE.” and no filter-failure table. Tick, step and notional violations arrive as dedicated codes instead:

Futures codeNameOfficial message
-4014PRICE_NOT_INCREASED_BY_TICK_SIZE“Price not increased by tick size.”
-4023QTY_NOT_INCREASED_BY_STEP_SIZE“Qty not increased by step size.”
-4164MIN_NOTIONAL“Order’s notional must be no smaller than %s (unless you choose reduce only)”
-4131MARKET_ORDER_REJECT“The counterparty’s best price does not meet the PERCENT_PRICE filter limit”

An error handler that parses Filter failure: will never match a futures rejection. Handle the two APIs separately. The futures minimum-notional case, including its reduce-only exception, is covered in Binance futures error -4164.

How to confirm which one you have

  1. Log the full response body, not just the code. The filter name is in msg.
  2. Fetch the symbol’s filters from exchangeInfo on the same base URL you traded against.
  3. Compare the exact string you sent — price and quantity as they went on the wire — against the relevant filter.
  4. Check order type. A market order is checked against MARKET_LOT_SIZE, not LOT_SIZE.

If msg does not begin with Filter failure:, read it literally; the filter family is the one Binance documents under -1013, and this page does not catalogue anything beyond it. Errors that did reach the matching engine come back under a different code — see Binance API error -2010. How this refusal fits alongside ambiguous outcomes is in error handling patterns for trading APIs.

FAQ

What does “Filter failure: LOT_SIZE” mean on Binance?

The order’s quantity is above the symbol’s maximum, below its minimum, or not a multiple of its step size. The bounds and step are in the symbol’s entry in GET /api/v3/exchangeInfo. Round the quantity down to the step and check it against the bounds before resubmitting.

What is the difference between MIN_NOTIONAL and NOTIONAL?

Both check price * quantity. MIN_NOTIONAL fails when that value is too low. NOTIONAL fails when it falls outside a range with both a minNotional and a maxNotional, so an order can fail it for being too large as well as too small. Check which bound applies before resizing.

Was my order placed if I got -1013?

No. Binance documents -1013 as a rejection by the API before the request reached the matching engine, so nothing rested and nothing filled. You can correct the field named in the Filter failure message and resubmit without reconciling first.

Why don’t I see “Filter failure” errors on Binance futures?

USDⓈ-M futures does not report filter violations that way. Its -1013 carries only “INVALID_MESSAGE.”, and tick, step and notional violations arrive as dedicated codes: -4014, -4023, -4164 and -4131. Handle Spot and futures errors separately.