---
title: "Diagnosing Binance Signature Error -1022 in JavaScript"
description: "Isolate Binance signature error -1022 with one signed account read, then check key type, environment, serialization, and timestamp errors separately."
canonical: "https://siebly.io/blog/troubleshooting-binance-api-error-1022-in-javascript-diagnose-invalid-signatures"
---
# Diagnosing Binance Signature Error -1022 in JavaScript
Isolate Binance signature error -1022 with one signed account read, then check key type, environment, serialization, and timestamp errors separately.
## Technical Disclaimer
These articles are software engineering references for exchange API integrations. They are not financial, investment, legal, tax, compliance, or trading advice. Use public data, demo, testnet, or paper workflows first. Keep API credentials out of frontend code and disable withdrawal permissions for automation keys.
## Identify the Returned Error {#overview}
A public Binance ticker request succeeds, but a signed account read fails with `-1022`. The public call establishes that the host answers. It does not exercise the secret, signing key, or serialized private parameters.
Binance defines `-1022` as an invalid signature. Its [error reference](https://github.com/binance/binance-spot-api-docs/blob/master/errors.md) distinguishes it from `-1021` timestamp failures and `-2014` or `-2015` key, IP, and permission failures. Preserve the actual code before changing configuration; one failure can hide another until it is corrected.
The following investigation uses one read-only Spot operation. An order placement introduces symbol filters, account settings, and trading permissions that are unnecessary when isolating signing.
## Run One Signed Account Read {#one-signed-call}
Install [binance](/sdk/binance/javascript) and save this as `binance-signature-check.mjs`. Both credentials must belong to the production Spot API selected by this configuration. The program prints only a success flag or the returned code, rather than an account response or a signed URL:
```js title="binance-signature-check.mjs"
import { MainClient } from 'binance';
const api_key = process.env.BINANCE_API_KEY;
const api_secret = process.env.BINANCE_API_SECRET;
if (!api_key || !api_secret) throw new Error('Set both Binance credentials');
const client = new MainClient({ api_key, api_secret });
try {
await client.getAccountInformation();
console.log({ signedAccountRead: 'succeeded' });
} catch (error) {
const code = error && typeof error === 'object' ? error.code : undefined;
console.error({ signedAccountRead: 'failed', code: code ?? 'no exchange code' });
process.exitCode = 1;
}
```
A success verifies that this key and signer worked for this operation at that moment. A network failure without an exchange code needs a separate investigation of routing, TLS, or the [proxy](/blog/using-proxy-with-siebly-sdks). It does not establish whether the signature would be accepted.
For another environment, select the SDK option deliberately and supply credentials created there. `testnet: true` and `demoTrading: true` select different hosts. A key from the wrong environment can cause a key or authentication failure; it does not guarantee a particular error code.
## Inspect the SDK Signing Boundary {#how-this-sdk-signs}
The [Binance SDK](/sdk/binance/javascript) signs private REST parameters before adding the signature to the request URL. A normal secret selects HMAC-SHA256. Supported PEM private keys select RSA or Ed25519. The property names are `api_key` and `api_secret`, which differ from raw WebSocket API parameter names.
Check the credential type first. An HMAC secret with an extra newline is a different secret. RSA and Ed25519 need the private signing material, including its PEM boundaries and line breaks, rather than the public key uploaded to Binance. The [authentication examples](https://github.com/sieblyio/binance/tree/master/examples/auth) show each supported type.
Next remove custom request transformations. Parameters added through Axios configuration or a serializer after signing can change the request without changing its signature. The SDK's second constructor argument is networking configuration; endpoint parameters belong on the method call.
Pass unencoded values to the SDK and omit unused optional fields. Pre-encoding can change a value through double encoding, and `undefined` can become an unwanted parameter. These are request-construction mistakes, but they do not inevitably cause `-1022` if the resulting bytes are signed and transmitted consistently. Read the returned error instead of assuming the signature failed.
Binance's [REST signing examples](https://github.com/binance/binance-spot-api-docs/blob/master/rest-api.md#signed-endpoint-security) specify the payload and encoding order. A raw implementation must follow that contract. The [signature-bytes article](/blog/crypto-exchange-request-signing-in-javascript-a-professional-engineering-guide) isolates serialization differences using synthetic secrets, without logging private requests.
## Separate Timestamp Failures {#when-you-are-stuck}
A correctly signed request can still fail its time window. The SDK adds its timestamp and receive-window fields; an incorrect host clock or a long delay after signing can make those values unacceptable.
The [timestamp diagnostic](/blog/crypto-exchange-api-timestamp-management-in-nodejs-a-professional-engineering-guide) measures offset and transit time separately. Increasing `recvWindow` does not repair a wrong secret or a payload changed after signing. Change one cause at a time, then repeat the same read.
## Extend the Check Only When Needed {#prove-the-signature-without-a-fill}
Once the account read succeeds, an order-specific investigation can use Spot `testNewOrder()` or the WebSocket API's `testSpotOrder()`. Binance validates those requests without sending them to the matching engine. Their quantities still need valid instrument filters, and success does not demonstrate real matching or fills. The [Binance tutorial](/sdk/binance/javascript/tutorial) supplies the corresponding examples.
WebSocket commands use their own signing and session rules. Ed25519 supports session login; HMAC and RSA use signed requests. A public server-time reply on that socket still does not establish private authentication. Close the client after a short diagnostic so an idle connection does not keep the process alive.
Keep retries bounded. `getRateLimitStates()` exposes the REST client's observed rate-limit headers, but it does not schedule or delay requests. The [rate-limit article](/blog/handling-crypto-exchange-api-rate-limits-in-javascript-and-nodejs) implements a weighted read queue and interprets exchange cooldowns.
When sharing a reproduction, include the package version, client class, environment, method, parameter names, and returned code. Use synthetic signing fixtures for byte-level comparisons. Complete exceptions can contain signed URLs, authentication headers, or account data and should not be copied into support reports.
## Related articles
- [Debugging the Bytes in an Exchange Signature](/blog/crypto-exchange-request-signing-in-javascript-a-professional-engineering-guide)
- [Binance User Data Stream 410 Gone: Fix Spot listenKey in JavaScript](/blog/binance-user-data-stream-410-gone-listenkey-javascript)
- [Choosing a JavaScript Exchange SDK](/blog/choose-javascript-crypto-exchange-sdk)
## Related Siebly Resources
- [Binance JavaScript SDK](/sdk/binance/javascript)
- [Bybit JavaScript SDK](/sdk/bybit/javascript)
- [OKX JavaScript SDK](/sdk/okx/javascript)
- [Siebly SDK directory](/sdk)
- [Exchange State Management](/ai/exchange-state)