Input & Output | Solana

Shared Input Pattern

Every operation on this node takes the same two mandatory top-level config keys, plus its own operation-specific fields:

Key	Required	Description
`resource`	✓ Yes	One of `account`, `block`, `transaction`, `token`, `nft`, `staking`, `program`, `wallet`, `nonce`, `utility`.
`operation`	✓ Yes	The operation within that resource, e.g. `balance`. `balance` and `get` are each shared by two different resources — always paired with `resource` to disambiguate.
`cluster`	No	Ignored by `utility/convertUnits` (no network call). Defaults to `Solana:DefaultCluster` for everything else — see Clusters.
`credentialID`	Only for the 6 signing operations	Vault reference to a `CRYPTO_WALLET` credential — see Signing & Credentials.

Everything else is specific to the chosen resource + operation pair — see that resource's page for the exact field list.

Numbers as Text

Every field carrying a lamport/token-amount value (lamports, amount) is configured and echoed as text, not a numeric control — ulong values (up to ~1.8×10¹⁹) exceed JavaScript/JSON's safe integer range (Number.MAX_SAFE_INTEGER, ~9×10¹⁵), so numeric controls risk silent precision loss on large values. This mirrors the same convention Ethereum's wei/gasLimit fields use on this platform.

Shared Output Shape

A successful call returns a JSON object whose shape is documented on each operation's page, wrapped in the platform's standard items array. There's no additional envelope beyond what's shown there plus three metadata fields common to every operation's outputData:

Metadata Field	Value
`status`	`"success"` on the success path.
`resource`	Echoes the requested `resource`.
`operation`	Echoes the requested `operation`.

staking/getValidators additionally includes a count metadata field alongside its array result.

How Errors Surface

Situation	What happens
Missing a required operation-specific field	A `VAL_MISSING_*` validation error (e.g. `VAL_MISSING_ADDRESS`) is returned before any network call — see each resource page for the exact codes.
Missing/blank `credentialID` on a signing operation	A dedicated "No signing credential configured..." error — see Signing & Credentials.
Invalid secret key material	`SolanaInvalidKeyMaterialException` — see Signing & Credentials.
Unknown/unconfigured `cluster`	`SolanaClusterNotConfiguredException` before any HTTP call is made — see Clusters.
RPC node returns "account not found" (e.g. address/signature/mint doesn't exist)	Surfaces as a node-level error result via the underlying service's `Success = false` path — check the address and cluster are correct.
RPC rate limiting (HTTP 429)	Retried automatically up to 3 times with backoff before surfacing as an error — see Troubleshooting.
Any other exception during execution	Caught and returned as a node-level error including the resource/operation and the target address/signature/mint for context.

Reads are idempotent; writes are not: Calling any of the 11 read operations twice with the same input is always safe. The 6 signing operations submit a real transaction each time — calling transaction/sendNative twice sends SOL twice. token/createAta is the one signing operation that's explicitly idempotent (returns alreadyExisted: true instead of erroring or double-creating).