Binance API rate limits and error -1003
Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs before acting on a number.
Binance meters API usage by request weight, not by request count. Different endpoints cost different amounts, so “how many requests per minute can I make” has no single answer — it depends entirely on which ones.
That is the thing to internalise, because a client designed around a requests-per-minute budget will behave unpredictably: fine for a while, then suddenly not, depending on which endpoints it happened to call.
The codes
| Signal | Meaning |
|---|---|
-1003 TOO_MANY_REQUESTS | Request weight exceeded, with messages about weight used against the current limit |
HTTP 429 | Rate limit response |
HTTP 418 | IP ban — escalation after severe or repeated violations |
HTTP 4XX | Client error generally |
HTTP 5XX | Server error |
The distinction between 429 and 418 is the important one. 429 is
ordinary throttling: back off and continue. 418 is a ban, it persists beyond
the burst that caused it, and it is what you get for ignoring 429 repeatedly.
If you take one operational rule from this: back off properly on 429, and
you will not meet 418.
Why weight changes how you design the client
Per-endpoint weights live in Binance’s own documentation and change, so look them up rather than trusting a number here. The structural points that do not change:
Bulk and unfiltered queries cost more. Asking for all symbols costs substantially more than asking for one. A convenience call that fetches everything and filters client-side is the usual way a client burns its budget without appearing busy.
Order placement and account queries are not free. It is easy to build a polling loop that consumes most of the budget before any trading happens.
Responses carry usage headers. Binance returns current weight usage in response headers. A client that reads them can throttle on actual consumption instead of a guessed request count, which is the difference between a budget that works and one that approximately works.
The part that is not merely operational
Rate limiting stops being an ops topic the moment it fires on an order.
CCXT classifies RateLimitExceeded under NetworkError, which sits under
OperationFailed — the branch meaning the outcome is unknown. The other
branch, ExchangeError, means the exchange understood and refused.
That classification is correct and has a consequence. A rate-limit response on a
read is a nuisance: retry, get the data. A rate-limit response on createOrder
is ambiguous — was the request rejected at the gate, or did it reach the
matching engine before the limiter caught up?
Usually the former. “Usually” is not a property you want deciding whether a retry doubles your position.
So: never blind-retry an order after a rate-limit error. Reconcile — query open orders, recent fills and the position — then decide.
And do not reach for a client order ID as the safety net. Binance documents
newClientOrderId as “a unique id among open orders”, with orders reusing an ID
accepted “only when the previous one is filled”. It blocks the duplicate while
the original rests and permits it once filled — the exact case you needed
protection for.
Designing around it
Reserve headroom for cancels. Whatever budget you have, some of it should be unavailable to routine polling. Being unable to exit because a data refresh exhausted your weight is the worst version of this problem.
Separate read traffic from order traffic. Reads are the bulk of the volume. If one limiter governs both, an exploratory query can block an order.
Prefer WebSocket for anything continuous. Streams do not consume REST weight per update. A client polling for price data that could be streamed is spending its budget on the one thing best solved another way.
Throttle on observed weight, not assumed count. The response headers tell you where you are.
Cache what does not change. exchangeInfo is not free and does not need
fetching every loop.
If you are already banned
418 means an IP ban. Practically:
- Stop making requests. Continuing can extend it.
- Fix the cause before resuming — a client that earned a ban once will earn it again on restart.
- Do not rotate IPs to get around it. That treats a symptom and risks a harder response.
- Come back with backoff and weight-aware throttling in place.
FAQ
What does Binance error -1003 mean?
TOO_MANY_REQUESTS — you exceeded the request weight limit, with messages
describing weight used against the current limit. It is weight-based rather than
count-based, so the endpoints you called matter as much as how many times you
called them. Severe or repeated violations escalate to an IP ban signalled by
HTTP 418.
What is the difference between HTTP 429 and 418 on Binance?
429 is the ordinary rate-limit response: back off and continue. 418 is an IP
ban, applied after severe or repeated violations, and it outlasts the burst that
caused it. Handling 429 properly is what keeps you from seeing 418.
How many requests per minute can I make?
There is no single answer, because Binance meters weight rather than count and endpoints have different weights. Read the per-endpoint weights in Binance’s documentation, and throttle against the usage reported in response headers rather than against an assumed request budget.
Is it safe to retry an order that hit a rate limit?
Not without reconciling first. CCXT places RateLimitExceeded under
NetworkError and OperationFailed, meaning the outcome is unknown. Query open
orders, recent fills and your position before sending anything, and do not rely
on newClientOrderId for protection — its uniqueness is scoped to open orders
only.