Input & Output
The shared config-key pattern, output envelope, and how errors surface — both variants
Shared Config Keys
| Key | Advanced Trade | Server Wallet |
|---|---|---|
resource | ✓ Required | ✓ Required |
operation | ✓ Required | ✓ Required |
credentialId | ✓ Required — CDP API key | ✓ Required — CDP API key |
walletSecretCredentialId | n/a | Required for fund-moving and fail-closed operations — see each resource page |
network | n/a — always production Coinbase exchange | Optional on network-scoped operations — see Networks |
Every operation also accepts its own operation-specific fields, documented on that resource's page.
Output Envelope
Both node types share the same output convention: every successful operation returns items[], wrapping either a single record or a list, via the shared WrapJsonIntoItems/WriteOutputData helpers.
- Single-record operations (e.g.
orders/get,account/getOrCreate) still return their one record inside a one-elementitemsarray — downstream nodes don't need to branch on shape. - List operations (e.g.
orders/list,account/listBalances) return oneitemsentry per record. - Confirmation-only operations (e.g.
portfolios/delete,policy/delete) return success/failure with no payload beyond that.
Error Surface
A failed operation writes an error code and message to the node's Error output port (via resultManager.SetResultAsError) instead of populating items[]. See Troubleshooting for the full code taxonomy of both variants.
Missing-credential messages are explicit. Both executors return a plain-English error — e.g. "Coinbase Advanced Trade requires a CDP API key credential with both a Key ID and a private key. Configure 'credentialID' on this node to a vault entry containing both fields." — rather than a raw HTTP 401, so misconfiguration is diagnosable without reading logs.