Authentication | Binance

Two-field credential: Binance's signed endpoints need both an API key and an API secret — unlike single-value credentials such as a bearer token. This node reuses the framework's existing key/value credential shape rather than introducing a custom resolver.

Setting Up a Credential

In the vault, create an API-key-type credential record for your Binance account.
Store your Binance API key as the record's Username/key field and your Binance API secret as the record's Password/value field.
Reference that vault entry via the credentialId config key on the Binance node.

Internally, ReadCredentialKeyValuePrimaryAsync resolves the vault record into a KeyValueCredential, and the executor maps Username → ApiKey, Password → ApiSecret — the same mechanism the Twilio node uses for its own two-field AccountSid/AuthToken credential.

Resource	`credentialId` requirement
`account`	Mandatory
`order`	Mandatory
`marketData`	Optional — Binance's market data endpoints are public and need no signature. Supplying a credential is still honored and raises the per-IP rate-limit bracket.

Missing or incomplete credential: If credentialId is required for the chosen resource and the vault entry is missing, or is missing either the API key or the API secret, the node returns an error without making any HTTP call:
"Binance requires an API-key credential with both an API key and an API secret. Configure 'credentialID' on this node to a vault entry containing both fields."

How Requests Are Signed

Every signed (account/order) request is authenticated with HMAC-SHA256 (System.Security.Cryptography.HMACSHA256 — no external crypto package) over the request's query/body parameters, using your API secret as the signing key. Binance also requires:

A timestamp parameter on every signed request
A recvWindow parameter (defaults to Binance:RecvWindowMs, 5000ms) bounding how far the server clock and request timestamp may drift apart
Your API key sent as the X-MBX-APIKEY header

The credential itself (BinanceApiCredential) is never held as state on any singleton service — it's resolved once per execution by the executor and passed down as a plain parameter to every service/client call, so there's no risk of one workflow's credential leaking into another's request.

Clock skew: If the host machine's clock drifts too far from Binance's server time, signed requests are rejected with BINANCE_TIMESTAMP_OUT_OF_RECV_WINDOW — see Error Codes and Troubleshooting.

Never share your API secret outside the vault. Store it only as a vault credential value — never inline it in a workflow config field, log statement, or exported workflow definition.