API guides

Treasury

Accounts and balances, behind the verification gate.

The API isn’t switched on in this environment yet. Everything below is accurate; the examples come from the published contract rather than a live read.

Treasury — coming

The treasury family is described in the contract and is not switched on here yet. Calls to it answer not_enabled until it is. We are not giving a date; when it answers, this page says so on its own — it reads the API’s enablement, the same answer the API’s own gate gives.

Two reads, both requiring the treasury:read scope. Balances are exact decimal strings at the asset’s decimals scale, never floats — parse one into a binary float and you introduce the rounding error the string exists to avoid.

Accounts

Your organization’s treasury accounts — the bank and value accounts behind the Treasury surface — each with its ledger-derived balance. Contra and bookkeeping accounts are not value accounts and never appear.

List accounts
From the published contract
curl "https://api.rivet.network/v1/treasury/accounts" \
  -H "Authorization: Bearer rk_live_…"
TreasuryAccount
FieldTypeNotes
id*string
account_kind*stringFIAT_BANK · FIAT_INTERNAL · CRYPTO_WALLET · MOBILE_MONEY
label*string
currency*string | null
balance*stringAn exact decimal, as a string, at the asset's decimals scale — never a float.

Balances

The same accounts projected down to the balance alone — the lighter read when you are polling for movement rather than rendering the accounts themselves.

List balances
From the published contract
curl "https://api.rivet.network/v1/treasury/balances" \
  -H "Authorization: Bearer rk_live_…"
TreasuryBalance
FieldTypeNotes
account_id*string
currency*string | null
decimals*integer | null
balance*stringAn exact decimal, as a string, at the asset's decimals scale — never a float.

What stands in front of it

Treasury is gated twice: the family has to be switched on in the environment, and your organization has to be verified. A key can hold treasury:read before either is true — the scope is what the key may ask for, not a promise that an answer exists yet. Until both are true you get not_enabled or capability_unavailable, never a misleading empty list.
  • A key without the scope: 403 insufficient_scope — it was never granted.
  • The scope, on an unverified organization: 403 capability_unavailable — the key may ask, the organization may not answer. This is not an empty list, and you should not render it as “no accounts”.
  • The family switched off here: 503 not_enabled. Switched on but its backing service unreachable: 503 service_unavailable.