Everything the ledger holds about one node, including the individual credits it has received and every withdrawal made against it.
Request
Request
GET /api/node/12
GET /api/node/12?limit=200
Parameter
In
Rules
id
Path
Either the chain node id or the ledger row id. Both are echoed back, so the answer always says which node you got.
limit
Query
How many credits and withdrawals to return. Default 50, maximum 200. Applies to each list separately.
Accepting either id is safe here because this is a read with no side effects. Anything that writes takes the chain node id only, never the ledger row id: that is true of POST /api/nodes/sync, and it is true of the contract, which has never heard of a row id. Passing a row id to withdraw would name a different node. See Node numbering.
Owner as recorded in the ledger, lower case. The contract is authoritative through the first value nodeInfo(id) returns.
priceWei
string
What was actually paid for this node, in wei, at the time it was minted
Credit fields
Field
Type
Meaning
id
number
Credit row id
distributionId
number
The round this credit belongs to. Cross-reference with GET /api/distributions to see the round total and its funding mode.
amountWei
string
Credited to this node in that round
createdAt
string or null
ISO 8601 UTC
Withdrawal fields
This list is the ledger’s record of withdrawals against the node. It is history, not permission: the server plays no part in a withdrawal, which is a call the owner’s own wallet makes to the factory. Two of the columns below are leftovers from an older design and no longer carry a meaning; they are documented so nobody reads one as something it is not.
Field
Type
Meaning
id
number
Withdrawal row id in the ledger. It has no meaning on chain.
amountWei
string
Paid out by this withdrawal
cumulativeSignedWei
string
A leftover column. No server signs anything that permits a withdrawal, so this carries no current meaning. Do not build against it.
toAddress
string or null
Where the ETH was sent, which is the to argument the owner passed to withdraw. Not necessarily the owner’s own address.
deadline
number
A leftover column. Withdrawals have no expiry and no time limit of any kind. Ignore it.
txHash
string or null
The transaction the withdrawal happened in, once one is known
status
string or null
One of signed, sent or failed, the three the column allows. sent is a withdrawal that went through and failed one that reverted.
createdAt
string or null
ISO 8601 UTC, when the row was written
confirmedAt
string or null
When the receipt was seen. Null until then.
A failed row is a transaction that reverted. It costs the sender gas and leaves the node’s balance exactly where it was, because a revert undoes everything in the call. What the contract can revert with is on Factory interface.
The authoritative withdrawal history is on chain, in the Withdrawn event and in the totalWithdrawnByNode figure nodeInfo(id) returns. This list can lag it, and it can be missing rows for a withdrawal the ledger has not observed yet. Where the two disagree, the chain is right. See Events.
Ordering and paging
Both lists are newest first, ordered by creation time then id. There is no cursor; use limit to widen the window, up to 200 rows per list. For a full history of a long-lived node, read the chain logs instead; see Events.
The id is not a positive whole number, or the limit is out of range
404
{ "error": "No node with that id." }
No node matches under either id space
429
{ "error": "Too many requests…" }
Over the per-IP limit
Example
curl and jq
# what this node has been credited, round by round
curl -s https://sitowise.xyz/api/node/12 \
| jq -r '.credits[] | "\(.createdAt) \(.amountWei)"'
# every destination this node has ever paid out to
curl -s https://sitowise.xyz/api/node/12 \
| jq -r '.withdrawals[] | select(.status == "sent") | .toAddress' \
| sort -u
Sitowise