This page shows you how to read the signed-in user's wallets and transactions. A
wallet holds a balance, and a transaction is one movement of it. You need a user
access token with wallet:read for wallets and wallet_transactions:read for
transactions.
Wallets
curl "https://api.davi.social/api/v1/wallets?details=true" \
-H "Authorization: Bearer ACCESS_TOKEN"
GET /wallets (scope wallet:read) lists the caller's wallets. With
details=true, each wallet includes its balance and its organization and
membership context, so a list needs no extra call per wallet.
A wallet is addressed by its address, not a UUID:
| Endpoint | Returns |
|---|---|
GET /wallets/{wallet_address} | The wallet |
GET /wallets/{wallet_address}/details | The wallet with balance and org/membership context |
GET /wallets/{wallet_address}/balance | The current point balance alone |
If you only show a balance, use /balance. It is the cheapest of the three and
safe to poll.
Transactions
| Endpoint | Scope | For |
|---|---|---|
GET /wallets/{wallet_address}/transactions | wallet_transactions:read | One wallet's history, most recent first |
GET /wallets/{wallet_address}/transactions/recent | wallet_transactions:read | The same, enriched with sender information |
GET /transactions | wallet_transactions:read | Across the caller's wallets |
GET /transactions/{transaction_id} | wallet_transactions:read | One transaction |
The recent variant resolves who sent each transaction; the plain history does
not. Use recent for a human-readable feed and the plain history for
reconciliation.
Reading what a transaction carried
A transaction that delivered reward content carries that content encrypted. Two routes reach it, and they are not interchangeable.
# The transaction's own content: decrypt, then fetch the manifest URL it returns.
curl -X POST "https://api.davi.social/api/v1/transactions/TRANSACTION_ID/decrypt" \
-H "Authorization: Bearer ACCESS_TOKEN"
| Route | Scope | Returns | Use it for |
|---|---|---|---|
POST /transactions/{transaction_id}/decrypt | wallet:decrypt | A manifest URL, which you then fetch | A transaction detail view |
GET /rewards/transactions/{transaction_id} | reward:read | A cached projection of the same content | A rewards or achievements list |
decrypt takes two steps because a manifest can be large, so the content is not
inlined into every read. A transaction detail view shows what that ledger entry
actually carries, so it uses decrypt rather than the cached projection. The
cached route exists for lists of what somebody holds, where the cache keeps them
cheap.
Next
- Fetching a Card: the cards bound to these wallets.
- Rewards: what puts content into a transaction.