binance-api-node: a typed Binance wrapper for Node and the browser

A wrapper with a single job and a clear scope

binance-api-node describes itself as a complete and heavily tested wrapper with typings for the Binance API, and the scope is deliberately narrow: one exchange, its REST endpoints and its websocket streams. The endpoint inventory in the project overview is long and grouped by market type. Public REST covers ping, time, exchangeInfo, book, candles, aggTrades, trades, dailyStats, avgPrice, prices and allBookTickers. The same set is mirrored for futures, with a markPrice and force-order call added, and again for delivery futures. The authenticated side is larger still, with order, updateOrder, orderTest, orderOco, getOrder, cancelOrder, cancelOpenOrders, openOrders, allOrders, accountInfo, myTrades, dailyAccountSnapshot, withdrawHistory, withdraw, depositAddress, depositHistory, tradeFee, capitalConfigs, universalTransfer, dustLog, dustTransfer and more. Every REST method returns a Promise, so the whole surface is async-await ready.

Installing and creating the first client

The package installs from npm in one command.

npm install binance-api-node

Getting started is a matter of importing the module and creating a client. Passing API keys is optional if you do not intend to make authenticated calls, and the project links to the page where you create an API key, plus a separate demo and testnet option.

import Binance from 'binance-api-node'

const client = Binance()

// Authenticated client, can make signed calls
const client2 = Binance({
  apiKey: 'xxx',
  apiSecret: 'xxx',
  getTime: xxx,
})

client.time().then(time => console.log(time))

The getTime option is the part worth pausing on. Signed requests need a server timestamp, and the client is handed the means to get one rather than assuming it can reach the exchange clock itself, which is the piece that usually causes signature errors in a wrong-timezone environment.

Testnet, RSA keys and ED25519 signing

Two options make this more than the usual key and secret pair. The first is the testnet boolean, which points the whole client at the demo environment.

const client = Binance({
  apiKey: 'xxx',
  apiSecret: 'xxx',
  getTime: xxx,
  testnet: true,
})

The second is key type. The project states that it supports RSA and ED25519 keys out of the box, and that the usage is straightforward: provide privateKey instead of apiSecret.

const apiKey = "ZymCbCxu1LiYIW8IcYSbXQOaAtHaeW3ioCU5qFf5QvUyTfP1runCaY8AwzCaoOaq"
const privateKey = "-----BEGIN PRIVATE KEY-----\ndMC4CAfAwafYDK2cwaCIEIa+Ax8dMK50wcIcD0Zdf2jaCDoRdaoc7KaadRUh+aLdt\n-----END PRIVATE KEY-----"
const client = Binance({
    privateKey,
    apiKey,
})

This is the practical difference between this wrapper and a hand-rolled signing function: you never touch the signature format, and the library works with whatever key type your account is configured for.

Proxy support that covers websockets as well as REST

Proxy configuration is a first-class option rather than an environment variable you have to hope is picked up. It is available in Node.js, and it applies to every HTTP request and websocket connection the client makes.

const client = Binance({
  apiKey: 'xxx',
  apiSecret: 'xxx',
  proxy: 'http://proxy-host:port',
})

// All HTTP requests and WebSocket connections will use the proxy
await client.time()
client.ws.ticker('BTCUSDT', ticker => console.log(ticker))

The notes in the overview list the constraints: proxy support is only available in the Node.js environment, browsers use system or OS proxy settings automatically, both HTTP and HTTPS proxies work with the http:// or https:// protocol, and authenticated proxies are supported in the form http://username:password@proxy-host:port. The websocket part is the detail that matters for a trading bot, since a stream that ignores the proxy leaks your real address even when the REST calls are proxied.

Node and browser need different import lines

The library works in both browsers and Node.js, and the difference shows up in one place: the module format. With a suitable babel configuration you use the default import shown earlier, and if you do not have an appropriate babel config you need the basic CommonJS require instead.

const Binance = require('binance-api-node').default

The package manifest reflects this split deliberately. The main entry points at dist, the browser field maps crypto to false and pins the http-client module for browser bundlers, and the exports map gives the types entry for TypeScript and the default entry for the compiled code. There is a separate note about Promises: the wrapper uses them throughout, and if they are not supported in your environment you may want to add a polyfill. The websocket layer is handled by isomorphic-ws, which is why the same code can open a stream in either environment.

The test suite runs in a browser, not just in Node

The claim of being heavily tested is backed by a specific setup. The package scripts run ava for the Node tests with a 90 second timeout, and then a separate browser test job that boots a browser test runner and runs the websocket and crypto tests under Playwright with a 15 second timeout, with individual scripts for the signature, websocket and crypto cases. Coverage comes from nyc, and the report script pipes the text-lcov output to coveralls. On the static side there is eslint for the source, prettier with both a write and a check mode, and a typecheck script running tsc with noEmit. The ci script chains lint, prettier check and the tests, which means formatting failures are treated as build failures rather than as suggestions. The repository also ships examples, including separate ones for the order book, prices, creating an order, proxy use, and the margin and ordinary user websocket streams.

Where to file issues, and what the licensing picture looks like

Two things in the overview are worth reading carefully before you file anything. The first is that pull requests and issues belong to a different repository, the source repository, and the contribution guidelines and development instructions live in CONTRIBUTING.md. That arrangement is common for a project that publishes from a mirror, but it means the repository you are reading may not be the one where changes land. The second is the licence. The licence for this repository is not classified, and the overview does not state a licence identifier, so if your organisation needs a clear licence position for a dependency, that has to be settled with the maintainers rather than inferred. The last push to this repository was on 2026-06-08, which is the same moment as release 0.13.10, and the two earlier releases are 0.13.9 from 2026-04-07 and 0.13.8 from 2026-02-25, so the release cadence is regular even if modest.

One exchange, and the one API change to watch

The limit of this library is its scope, and the scope is the point. Every endpoint in the inventory belongs to Binance, and the README states the project is powered by ccxt, which is the project to look at when you need to cover several venues with one interface rather than one exchange with a complete one. If you only trade Binance, that focus is an advantage, because the coverage is deep enough to include the delivery futures endpoints and the capital and transfer calls, which a general-purpose client tends to leave out. The other thing to watch is the API itself. The overview notes that the wrapper fully supports the new algo service introduced on the 9th of December 2025, which is a reminder that a wrapper only stays complete while its author keeps up with the exchange, and that the endpoint table in the overview is where you can see whether the surface you need is there.

Editorial conclusion

binance-api-node fits a Node or browser developer who needs one exchange with a typed, promise based client and a websocket stream in the same package, especially if you need testnet keys, RSA or ED25519 signing, or an HTTP proxy, all of which the project supports directly. It does not fit a team that trades on more than one venue, since the scope here is the Binance API only, and the README points at the ccxt project as the one that powers this wrapper when you need a broader abstraction. It also does not fit anyone who needs a licence commitment, because the licence for this repository is not classified and the overview points to a separate source repository for pull requests and issues, where contribution guidelines live. Before you depend on it, check which repository you will actually be merging, since the overview sends pull requests and issues to the source repository rather than this one, and pin an exact version because the last push here was on 2026-06-08.

Frequently asked questions

Official sources

1. ccxt/binance-api-node on GitHub
2. Issues
3. README
4. Releases