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 three top-level config keys, plus its own operation-specific fields:
| Key | Required | Description |
|---|---|---|
resource | ✓ Yes | One of account, token, topic, transaction, utility. |
operation | ✓ Yes | The operation within that resource, e.g. getBalance. |
network | No | Ignored by utility operations (they don't call the network). Defaults to Hedera:DefaultNetwork for everything else. |
Everything else is specific to the chosen resource + operation pair — see that resource's page for the exact field list.
Shared Output Shape
A successful call returns a JSON object whose shape is documented on each operation's page. There's no additional wrapper envelope beyond what's shown there — the fields listed on each resource page are the output.
How Errors Surface
| Situation | What happens |
|---|---|
Unknown/unconfigured network |
Node throws HederaNetworkNotConfiguredException before any HTTP call is made. |
| Mirror Node returns 404 (e.g. account/token/topic/transaction doesn't exist) | Surfaces as a node-level error result — check the ID and network are correct. |
| Mirror Node returns 400 (malformed ID) | Surfaces as a validation-style error — run utility.validateAddress first if the ID comes from user input. |
| Mirror Node rate limiting (429) | See Troubleshooting for backoff guidance. |
Idempotent by nature: Because every current operation is a read, calling the same
operation twice with the same input is always safe — there's no risk of double-submitting a
transaction or double-charging a fee. That changes once signed writes ship — see
Roadmap.