Binance API

What an exchange API is

An exchange has a website where you click to trade. Behind it sits a program that answers messages. An API (application programming interface) lets your own program send those same messages. A request such as "what is the latest price" or "place this order" goes out, and a reply comes back in a data format, most often JSON, a plain text layout of names and values.

The Binance API is the interface of one large crypto exchange. The general shape is the same at most exchanges: a public part for market data, a private part for your account, and usually a testing environment. Which markets, order types and fields exist is a matter for the documentation of the venue, and it can change without notice. We have not read it for this page, so nothing here describes a specific field or limit.

The three kinds of call

• Public data. Prices, order books and recent trades. No key is needed because anyone can see them.
• Private reads. Your balance, open orders and past fills. These need a key and a signature.
• Private actions. Placing, changing and cancelling orders, and on some venues moving money. These need a key with the matching permission switched on.

Keys, secrets and signatures

An API key is a pair of strings. The key identifies you. The secret proves a message came from you. For each private request the bot builds the message, makes a signature from it and the secret using a method the documentation names, and sends the signature with the request. The secret itself is never sent. Anyone who holds the secret can act as you, so the rules are simple.

• Give each key only the permissions the bot needs. A bot that only reads needs no trading permission, and a trading bot does not need permission to withdraw.
• Keep the secret out of the code, out of screenshots, out of chat and out of any repository. Load it from a setting on your own machine.
• Check whether the venue lets you limit a key to certain network addresses, and use that if it does.
• Make a new key for each bot, so one leak can be cancelled without stopping the rest.

Worked example: rounding an order

Every market has rules about the size of an order. There is usually a smallest step for the quantity, a smallest step for the price, and a minimum order value. A bot that sends 0.0456 when the step is 0.001 will be rejected. The fix is to round down to the step before sending. The numbers below are made up: a quantity step of 0.001, a price step of 0.01 and a minimum order value of 10. The real values differ by market and change, and the venue publishes them in its market information.

Calculated by us on 31 Oct 2026, exact for the made-up filters. The third row shows the usual trap: a small order that rounds to a value under the minimum is rejected, and a bot that does not handle the rejection may retry forever or stop. Rounding down also means the order is a little smaller than intended, as the figure shows. That is the safe direction, since rounding up could spend more than the bot meant to.

Worked example: how many requests a loop makes

A simple bot asks for the price on a timer. Dividing the seconds in a day by the interval gives the number of requests: 86400 at every 1 seconds, 17280 at every 5 seconds, 5760 at every 15 seconds, 1440 at every 60 seconds, 288 at every 300 seconds. Venues limit how fast an account or an address may send requests, and breaking the limit can lead to refused requests or a temporary block. The limits are numbers that change, so read the current page of the venue and compare it with your loop. A stream of live data usually replaces a fast timer and uses far fewer requests.

How a bot using an API breaks

• Clock drift. Signed requests usually carry a time stamp, and a computer clock that is out of step can make every request fail.
• A reply that never came. If a network error hides whether an order was placed, the bot can send it twice. Use the way the venue lets you tag an order with your own id, if it has one, and check open orders before retrying.
• Silent changes. The venue can add a field, retire an address or change a rule. A bot that is not watched stops working or, worse, keeps working on wrong data.
• Partial fills. An order can fill in pieces. A bot that assumes all or nothing ends up with a position it does not know about. See slippage.
• Leaked keys. The most costly failure. See the safety rules above.

How to check your own setup

1. Test on a practice environment first if the venue offers one. See Binance testnet and paper trading.
2. Print every request and reply to a log file with the secret removed.
3. Round every quantity and price to the steps of the market and check the minimum value before sending.
4. Count your requests per day and compare with the current limits of the venue.
5. Start with a very small size and compare each real fill with what the bot expected.

What this page does not tell you

It does not give any address, field name, limit, fee or supported market, because those change and we did not read the documentation for this page. It does not say a bot using an API will make money. For the wider picture of building a bot see Python trading bot and crypto trading bot.