binance-connector-java: generated Java clients for the Binance API surface

One artifact per product area, and you take only what you use

The connectors are generated from OpenAPI specifications, and the repository is organised as a clients directory with one Maven module per Binance product area. The list in the README covers the Spot Trading connector, the Algo Trading connector, the Margin Trading connector, the Alpha, C2C, Convert and Copy Trading connectors, the Crypto Loan, Dual Investment, Simple Earn, Staking, Mining and VIP Loan connectors, the fiat, gift card, pay, rebate, wallet, NFT, stocks and sub-account connectors, and the derivatives group with separate modules for coin futures, options, portfolio margin, portfolio margin pro and USDS-M futures, plus a W3W Prediction connector. Each is published as a separate Maven dependency, so a project that only needs spot data does not have to pull the futures clients in. The topic tags on the repository cover market data, spot, trading, real-time and crypto, and the primary language is Java.

Adding one connector as a Maven dependency

The installation section shows a single dependency, and the pattern is the same for every connector:

<dependency>
  <groupId>io.github.binance</groupId>
  <artifactId>binance-spot</artifactId>
  <version>11.0.2</version>
</dependency>

The group id is io.github.binance and the artifact id matches the connector name, so the spot client is binance-spot. The version in the example is 11.0.2 for the spot artifact, and since each connector is versioned separately, the versions of different connectors are not necessarily in step. The prerequisite is Java version 11 or later, which the README also states in the badges as Java >= 11, and the project is MIT licensed with the licence badge in the header. Detailed endpoint-level documentation is not in this repository; the README points to the Binance API documentation at developers.binance.com for that.

Signing is configuration, and the key type is your choice

The most important part of the README for a new user is the signature generator section, because the connectors are useless without it. When creating REST clients such as SpotRestApi, you use a SignatureConfiguration to sign requests to SIGNED endpoints, and there are two styles. HMAC uses an API key and secret key:

    SignatureConfiguration signatureConfiguration = new SignatureConfiguration();
    signatureConfiguration.setApiKey("apiKey");
    signatureConfiguration.setSecretKey("secretKey");

RSA or ED25519 use the API key with an RSA or Ed25519 algorithm key, and the configuration takes a path to the private key plus, if the key is protected by a password, a separate pass value:

    SignatureConfiguration signatureConfiguration = new SignatureConfiguration();
    signatureConfiguration.setApiKey("apiKey");
    signatureConfiguration.setPrivateKey("path/to/private.key");
    // if the private key is protected by a password
    signatureConfiguration.setPrivateKeyPass("privateKeyPass");

The choice is per client, so a single application can use HMAC for one account and Ed25519 for another, which is the flexibility you want when the key policy is set per account rather than per codebase.

WebSocket clients take the same configuration objects

The WebSocket API clients, such as SpotWebSocketApi, use the same SignatureConfiguration and the same two key styles, but wrap them in a WebSocketClientConfiguration rather than a ClientConfiguration. The HMAC path sets the API key and secret key and hands the configuration to a WebSocketClientConfiguration, and the Ed25519 or RSA path sets the API key, the private key path and the optional key password in exactly the same way as for REST. The two families being configured identically is deliberate, since a trading application usually needs both a REST client for account queries and a WebSocket client for the streams, and having the credential wiring differ between them would be a common source of bugs. The client is then constructed from the configuration, so the credential object is the only piece that changes between the REST and streaming worlds.

A connection pool for stream consumers

For applications that hold a lot of streams open, the README documents a pool mode for both the WebSocket API and the WebSocket streams. In both cases the pattern is the same three steps: get a client configuration from the utility class, set the use pool flag to true, then construct the API. For the WebSocket API the utility is SpotWebSocketApiUtil.getClientConfiguration() and the client is SpotWebSocketApi, and for the streams it is SpotWebSocketStreamsUtil.getClientConfiguration() with SpotWebSocketStreams as the client. The distinction between the two APIs matters when you are choosing where to start. The WebSocket API is the request and response side over a socket, while the streams are the subscription side, and a market data consumer normally needs the streams and a trading system needs the API, sometimes both.

A proxy is configured the same way as anything else

The README also shows how to route REST calls through an HTTP proxy, using a ClientConfiguration from SpotRestApiUtil.getClientConfiguration() and then a Proxy built from a type and an InetSocketAddress. The example in the README is cut off mid-line, so the full address and port are not shown there, but the shape is clear from the code that is. The useful thing to note is that the proxy is not a separate client or a special path through the library. It is a standard JVM Proxy attached to the client configuration, which means the same mechanism works for any connector that takes a ClientConfiguration, not just spot.

Generated code, so the contribution path is unusual

The contributing section is the part that tells you how this repository differs from a hand-written library. Since the repository contains auto-generated code using OpenAPI Generator, the project asks that you open a GitHub issue to discuss ideas or report bugs, and that you let the maintainers implement the necessary changes through the code generation process. That is a coherent model for a connector suite: the API surface is defined by Binance's own specifications, so a hand-edited client would be overwritten on the next regeneration. The practical consequences for a user are that custom behaviour belongs in your own code rather than in the client, and that the generated clients will not carry your patches. The repository also carries a MIGRATION.md file and an examples directory with a project per connector, including a pom.xml and a checkstyle.xml, which are the closest thing to usage documentation for each client.

Editorial conclusion

binance-connector-java fits a Java team that wants typed, generated clients for the Binance API rather than hand-written HTTP calls, and that has decided which product areas it needs so it only depends on those artifacts. It does not fit a team that needs a change in the generated code itself, because the README asks you to open an issue and let the maintainers implement it through the code generation process. Before adopting it, pick the specific connector artifacts you need rather than the whole set, confirm the Java version in your build matches the required version 11 or later, and read MIGRATION.md, since the repository carries a migration guide alongside the generated clients.

Frequently asked questions

Official sources

1. binance/binance-connector-java on GitHub
2. Issues
3. License: MIT
4. README