Skip to main content
Points are the spendable currency of a member’s wallet. They are minted by your backend, spent when a member redeems an offer, and refunded when a redemption is canceled. Every change is recorded as a transaction you can read back as a ledger.
This page describes member-wallet settlement, the default. If your organization is on org-pool settlement, there are no per-VIP wallets at all: you never call POST /v1/wallet/credit, and a redemption debits your organization’s pool directly. Skip to Billing and settlement instead. Check which mode you are on with GET /v1/balance.
Two modes touch the wallet, and they use different credentials:
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 calls POST /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.
Minting is server-side only. It requires the Org-API-Key and must run on your backend - never in an app or mobile binary. A member token calling POST /v1/wallet/credit is rejected with 403 FORBIDDEN. The Org-API-Key has full org authority; treat it as a secret.
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").
Send an Idempotency-Key header so a retried mint replays the original result rather than crediting twice. See Retries and idempotency.
The response is a 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.
In the SDKs, minting is 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 a pointsPrice - 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 pointsPrice against the wallet balance before offering a redeem action, so the member never hits an INSUFFICIENT_POINTS error mid-flow.

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.
The same 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.
The response is a 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 passing nextCursor back as cursor until the server returns null:
The cursor loop is identical to every other list endpoint in the API, such as offers and the concierge message history.

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.

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.