Diagnosing Binance Signature Error -1022 in JavaScript

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 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.

Install binance 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:

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. 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.

The Binance SDK 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 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 specify the payload and encoding order. A raw implementation must follow that contract. The signature-bytes article isolates serialization differences using synthetic secrets, without logging private requests.

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 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.

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 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 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.