Member-mode calls authenticate with the short-lived member token your
backend mints (see Authentication), and the
environment - sandbox or live - is selected by the key the
token was minted from. Server-mode calls authenticate with the Org-API-Key
directly.
Mint points (server-side)
Minting credits points into a member’s wallet. Your backend callsPOST /v1/wallet/credit with the Org-API-Key. amount is an integer number
of points, and an optional reason is stored on the resulting credit
transaction.
string
required
Your stable identifier for the member to credit.
integer
required
The number of points to mint. A positive integer.
string
Optional free text stored on the credit transaction (for example
"welcome bonus").Idempotency-Key header so a retried mint replays the original result
rather than crediting twice. See
Retries and idempotency.
CreditWalletResponse with the member’s new balance:
number
required
The member’s wallet balance after the credit.
object
required
The wallet currency, with
name and symbol.creditPoints(...), one of the server-mode methods that
run with the Org-API-Key. The full server-mode flow - exchanging a member token,
upserting a member, and crediting points - looks like this:
Spend points (member-side)
Members spend points by redeeming an offer. Each offer carries apointsPrice - an integer points cost (or null for offers that are not
points-priced). Redeeming debits pointsPrice from the wallet; the redemption
records the spend.
If the member’s balance is below
pointsPrice, the redemption fails with
INSUFFICIENT_POINTS (422). Canceling a redemption refunds its
pointsPrice back to the wallet as a credit. The mechanics of submitting,
tracking, and canceling a redemption live in
Redemptions.
Read the balance (member-side)
GET /v1/wallet returns the current Wallet. It is a member-mode call - use the
member token.
number
required
The current spendable balance.
number
required
Lifetime total credited to this member.
number
required
Lifetime total debited from this member.
object
required
The wallet currency, with
name and symbol.Wallet is also embedded in the
eligibility response, so a single eligibility call gives
you tier and balance together:
Read the ledger (member-side)
GET /v1/wallet/transactions returns every wallet change as a list of
Transaction records, newest first, with cursor pagination. In the SDKs this is
walletTransactions(...).
integer
Page size. Defaults to the server’s default if omitted.
string
The
nextCursor from the previous page. Omit for the first page.string
Names the member when a machine token calls on their behalf.
ListTransactionsResponse:
Transaction[]
required
The page of transactions, newest first.
string | null
required
Pass this back as
cursor to fetch the next page. null marks the end of the
list.The Transaction schema
amount is signed, so summing the page reconciles against the wallet:
credits push balance and amountReceived up, debits push balance down and
amountSpent up. Follow redemptionID to tie a debit (and any later refund)
back to the redemption that caused it.Paginate the ledger
Keep passingnextCursor back as cursor until the server returns null:
The loop, end to end
1
Mint
Your backend credits points with the Org-API-Key
(
POST /v1/wallet/credit). The balance goes up; a credit transaction is
written.2
Spend
The member redeems an offer in the app.
pointsPrice is debited; a
negative transaction with the redemptionID is written.3
Refund
If that redemption is canceled,
pointsPrice is credited back; a positive
transaction carrying the same redemptionID is written.4
Audit
GET /v1/wallet shows the running balance and lifetime totals;
GET /v1/wallet/transactions replays the whole history.Related
Wallet
The wallet object, balances, and currency in depth.
Redemptions
How spending and refunds work through the redemption lifecycle.
Members
Identifying members by
externalUserID and their tier.Server mode
Backend calls with the Org-API-Key, including minting points.