Input & Output
The shared config-key pattern across every operation, and how errors surface
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:
| Key | Required | Description |
|---|---|---|
resource | ✓ Yes | One of account, order, marketData. |
operation | ✓ Yes | The operation within that resource, e.g. getAccountInfo. |
credentialId | Mandatory for account/order; optional for marketData | Vault 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:
- Single record — for operations that act on or return exactly one thing (e.g.
placeMarketOrder,getOrder,getOrderBookDepth). items[]+count— for operations that return a list (e.g.getAccountInfo,getOpenOrders,getKlines,getTickerPricewith nosymbol).
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
| Situation | What 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.