Skip to main content
Wallets hold your crypto balances — USDC, USDT and other stablecoins — along with the chain addresses money arrives on. This guide reads a wallet from the top down: find it, check what is in it, get its deposit addresses, then look at what has moved. Every call here is read-only. Nothing in this guide changes a balance.

What you’ll need

  • Your secret key, or a dashboard JWT. Wallet endpoints accept either.
  • Nothing else. Your wallets already exist — the main wallet is created with your account.
Wallets are for crypto. Your fiat balances (GHS, NGN, USD and the rest) live somewhere else entirely — see Read Your Balances. Two different systems, two different sets of endpoints.

The shape of the flow

1

List your wallets

See the main wallet and every sub-wallet under it.
2

Jump straight to the main wallet

A shortcut path that skips needing an ID.
3

Read the balances

What each wallet holds, per currency.
4

Get the deposit addresses

The chain addresses money can be sent to.
5

Read the activity

What has actually moved in and out.

Step 1: List your wallets

The response is paged. Pass page and size to walk it:
Unlike the marketplace endpoints, wallet endpoints accept either a secret key or a dashboard JWT. Both return the same data.

Step 2: Jump straight to the main wallet

If you only care about the main wallet, main works in place of an ID — no lookup needed:
Fetching a specific wallet by its ID returns the same shape:
An ID that does not exist returns 404 with wallet_not_found:
Keep the traceId if you need to raise it with support.

Step 3: Read the balances

main works here too:
balance and availableBalance are not the same number. In the response above the wallet total is 3.666667 but only 2.665712 is available — the difference is held against pending activity. Spend against availableBalance, never balance.
Any wallet works by ID, including a sub-wallet:
A sub-wallet keeps its own balances. Money in the main wallet is not spendable from a sub-wallet.

Step 4: Get the deposit addresses

These are the on-chain addresses money can be sent to.
Three things here will catch you out.
Filter on status: "active". The list returns inactive addresses alongside active ones — the real response above held 12 addresses across 5 chains, and only 5 were active. Sending to an inactive address is a good way to lose funds. Never show a user the first address in the array; pick the active one for the chain you want.
Stellar needs the memo. Stellar addresses carry memoType and memoValue, and several wallets share the same Stellar address with different memos. A deposit sent without the memo cannot be credited to you. Always pass both.
The chain values are network-specific and name the testnet in test mode — base_sepolia, ethereum_sepolia, polygon_amoy, stellar_testnet, tron_nile. Live mode returns the mainnet names. Never reuse a test address in production.
One address in the real response had a chain and a status but no address field at all — an address still being provisioned. Check the field exists before you use it.

Step 5: Read the activity

What has actually moved:
Newest first. The default page size is 20 here, not 10 as on /wallets:
A pending activity has not settled. It already shows in the list and is already reflected in the gap between balance and availableBalance, but the money has not landed. Reconcile on status: "successful" only.
Not every activity has a real chain hash. Internal movements — a trade settling, for instance — carry a HyperRails reference in hash like HPR-QUO-...-BATCH-COMPLETE rather than an on-chain hash. Do not feed those to a block explorer.

When things go wrong

What to do next