​

Marketing hub console map — wallet passes, loyalty, and referrals in one place

The Marketing docs split coverage by surface — a deep guide for wallet passes, a model page for loyalty, a campaign setup walkthrough for referrals — because that is how the features shipped. Operators do not work that way. A tenant rolling out a retention program asks one question: where do I set what? This page answers it, collecting the consoles under the Marketing hub in the dashboard into one map. Every console below is a tenant-owned control — you set it for your workspace, and nothing applies until you turn it on. Each maps 1:1 to a route under /marketing in the dashboard.

​

Why the hub is a map

The Marketing hub groups every control for the three retention surfaces that sit on top of your contact base: the cards your customers carry in Apple Wallet and Google Wallet, the points-and-tiers program those cards often display, and the referral programs that turn members into recruiters. One question brings an operator here — what do my customers hold, earn, and share? — and the hub answers it across three consoles. Operators rarely open the hub directly. You land on a console from the command palette, from a notification, or from the Outbound section’s referral links — which is why the bare /marketing route exists at all (see The bare /marketing route).

​

Console map

​

Wallet Passes — /marketing/wallet-passes

What it answers: what are my customers carrying in their phone wallets, and what state is each card in? The console lists issued Apple Wallet and Google Wallet passes — loyalty cards, coupons, event tickets — and drives their issue → update → void lifecycle. The generation counter on each pass is the holder-refresh signal: bump it and every device holding that pass refreshes its content without a re-save. First visit: the list is empty until a pass program exists. Open the console with no programs and you get the “create a pass type” picker — choose loyalty card, coupon, or event ticket before any contact receives anything (see the Wallet passes guide for the type differences in the lifecycle model). Docs: guide; lifecycle model.

​

Loyalty — /marketing/loyalty

What it answers: how do contacts earn, what tier are they on, and what can I do to a balance right now? The console holds the program configuration — earn rules and tiers — and, per member, the point balance with adjust and redeem actions. Adjust applies an explicit credit/debit with a reason; redeem burns points through the incentives engine and blocks overspend (see the Loyalty program model). First visit: with no program the console shows the earn-rule builder before anything else — tiers stay disabled until at least one earn rule exists, so the wizard enforces that order (see the Loyalty program guide). Docs: guide; model.

​

Referrals — /marketing/referrals

What it answers: who is recruiting whom, and what do we owe them? The console holds the reward definition (which pre-commit hook the payout rides — platform credit, a discount code, or a custom reward), per-contact share codes, the funnel KPI cards (visits / signups / paid out), the ranked leaderboard of referrers, and the pending-reward queue you approve payouts from. First visit: with no program the console centers on the reward definition — pick the reward type before any code can be issued. The Referral campaign setup guide runs this setup end-to-end without API calls, including the QR-code deep link pattern below (see the Referral program model for the payout rails). Deep-link a refer-a-friend from the Inbox: a conversation’s right rail has a referral action that issues the contact’s code and drops the public link (for example https://api.orbit.devotel.io/r/AbCdEf23) straight into the reply draft — the customer shares it as-is, or renders it as a QR code at the counter. Because each contact carries a separate code, cohort comparison (SMS push vs email vs counter QR) reads back on the leaderboard as separate rows. Docs: campaign setup; model; API workflow.

​

Permission scope per console

• Wallet Passes — API keys with contacts:write issue and void passes; reads accept contacts:read.
• Loyalty — program configuration (earn rules, tiers, adjust, redeem) follows dashboard workspace-role rules; members’ balances are read-only to roles without configuration access.
• Referrals — program creation, code issuance, and payout approval are gated to the owner, admin, and developer roles (the same guard the console itself enforces); reads — list, leaderboard, totals — need only authentication.

Every console is tenant-owned: programs, passes, codes, and balances live in your workspace only, nothing crosses tenant boundaries, and nothing applies until you create it.

​

Suggested rollout order

Touch the consoles in this order when you stand the surfaces up for the first time. Each step builds on the one above it:

1. Wallet Passes — issue the pass your customers will carry. A loyalty card with a scannable barcode is the membership artifact everything else hangs off; issue it before any points exist, because the pass id is what later balance updates target. Skip when: your membership is email/SMS-only with no wallet artifact — go straight to step 2.
2. Loyalty — define earn rules and tiers once passes are live. Members see balances climb on the card they already saved, and the pass generation counter tells holder wallets to refresh — no re-save needed. Skip when: you only run referrals today and prefer credit or discount-code payouts — the Referrals console can ride those rails without a points program.
3. Referrals — with members enrolled and earning, add the member-get-member loop. Referral rewards paying out in loyalty points read the program the Loyalty console defines. Skip when: acquisition is not a goal this quarter — steps 1–2 alone unblock a working membership.

Steps 1–2 unblock a working membership. Step 3 turns membership into acquisition.

​

The bare /marketing route

The bare /marketing path holds no console of its own and today always resolves to Referrals — the longest-standing tile in the group. It exists so that nav surfaces that deep-link into the hub (command palette, links from the Outbound section) resolve cleanly instead of 404ing; the redirect is a pass-through, not a placeholder page. If the hub ever grows more consoles, that route is where a tiled landing page would go; until then, bookmark the console you actually use, not the bare path. Old bookmarks still work: the canonical module moved into the marketing namespace, and /outbound/referrals and its program deep links redirect to the matching pages under /marketing/referrals.

​

Where the in-depth docs live

• Wallet passes guide — the end-to-end issue → deliver → update → void pipeline, with idempotency and campaign patterns.
• Wallet pass lifecycle — the three pass types, the generation counter as the holder-refresh signal, and the ledger the state machine is projected from.
• Loyalty program guide — earn rules, tiers, preview, redemption routing, and carrying the card in wallets.
• Loyalty program model — why balances are a projection over the CDP event stream, not a separate ledger, and how tier ladders and overspend-safe redemption work.
• Referral campaign setup — the same referral workflow run entirely from the dashboard, including cohort codes and QR distribution.
• Referral program model — program → code → conversion → reward, and how the public /r/:code redirect attributes signups.
• Referral programs guide — the API-side workflow: programs, per-contact codes, the leaderboard, and payouts through the incentives engine.

​

See also

• Wallet passes guide — the full issuance pipeline, in depth.
• Referral campaign setup — the dashboard-only referral walkthrough.
• Loyalty program setup — earn rules, tiers, and redemption from the operator side.
• Incentives ledger — the payout engine referral rewards and loyalty redemptions settle through.
• Inbox settings map — the same console-map treatment for the twelve Inbox → Settings consoles.