Wallet Passes
The Wallet Passes console at/marketing/wallet-passes manages the artifact your members carry in Apple Wallet and Google Wallet: loyalty cards, coupons, and event tickets. The console drives the issue → update → void lifecycle, and the generation counter on each pass is the refresh signal to holder devices. The marketing hub overview positions this console against the other three; the Wallet passes guide runs the issue → deliver → update → void pipeline end to end; the concept page defines the lifecycle underneath.
Wallet Passes is a tenant-owned control. Passes carry your brand, your fields, and your barcodes; the platform issues and refreshes exactly what you define.
What you see on the page
Issued passes. One table, newest first:
The table pages 25 rows at a time with Previous and Next, and a Contact ID filter with Apply narrows it to one member.
Issue pass. The header button opens the issue dialog:
- Pass type — loyalty card, coupon, or ticket
- Contact ID or External ref — who carries the pass, or your own order or ticket id
- Title and optional Subtitle — what the holder reads first
- Organization name and Description — your brand on the pass
- Barcode message — the scanned value at your counter, for example the member code
Who can read and who can act
The dashboard gates the console at the workspace level; the API splits reads from writes at the scope level:
A credential with only
contacts:read can list passes and receives a 403 on issue, update, and void.
Worked examples
Issue a loyalty card to a member
- Choose Issue pass.
- Set the pass type to loyalty card, the member’s Contact ID, your Organization name, and the member’s code as Barcode message.
- Confirm, then deliver the pass link over any channel you already use. The pass installs into the holder’s wallet.
Bump the generation counter
- Find the member’s active pass and choose Update.
- Change what moved — a new tier in the title, a refreshed barcode, a corrected description.
- Save. The row’s Generation goes up by one, and every device holding that pass refreshes its content without the member re-saving anything. That is the whole refresh contract: content change plus generation bump.
Void a pass when the membership ends
- Choose Void on the row. The console asks for confirmation, since the action cannot be undone.
- The status leaves
active, and Update and Void disable on the row, on the dashboard and in the API alike.
API pairing
The issue dialog writesPOST /api/v1/wallet-passes/issue:
POST /api/v1/wallet-passes/:id/update and POST /api/v1/wallet-passes/:id/void, the same calls the row buttons make; the update response reports the new generation. Loyalty writes the pass from the other side: when a member’s balance changes, the linked pass refreshes through the same generation bump.