Portal Community

Shared Input Pattern

Every operation on this node takes the same top-level config keys, plus its own operation-specific fields documented on that resource's page:

KeyRequiredDescription
resource✓ YesOne of account, order, marketData.
operation✓ YesThe operation within that resource, e.g. getAccountInfo.
credentialIdMandatory for account/order; optional for marketDataVault reference to an API-key credential holding both your Binance API key and secret. See Authentication.

Symbol Normalization

Every field named symbol across all 9 operations that take one is automatically uppercased before being sent to Binance (BinanceConfigParsingHelpers.NormalizeSymbol). Binance's trading pairs are case-sensitive on the wire — a lowercase value like btcusdt would otherwise be rejected.

Shared Output Shape

Two output shapes recur across operations:

The exact field list for each shape is documented on that operation's page — there's no additional wrapper envelope beyond what's shown there.

How Errors Surface

SituationWhat happens
Missing/incomplete credentialId on a mandatory resource Node returns an error before any HTTP call is made. See Authentication.
Both quantity and quoteOrderQty set on placeMarketOrder Rejected as a validation error before any HTTP call — exactly one is required, not both.
Binance API call fails (bad symbol, insufficient balance, rate limit, IP ban, etc.) Mapped to one of the BINANCE_* codes — see Error Codes.
Network failure or unexpected exception outside the mapped cases Surfaces as BINANCE_UPSTREAM_ERROR or an unexpected-error result.
Not idempotent by default: unlike a pure read, calling placeMarketOrder or placeLimitOrder twice with the same input places two orders — Binance does not deduplicate for you. Use newClientOrderId to give each order a stable, unique identifier if a workflow step might retry. Every read-only operation (account.*, marketData.*, and the order lookups) is always safe to repeat.