Messaging channels deliver a moment. A wallet pass delivers a document. SMS, WhatsApp, and voice move a conversation forward right now; a loyalty card or event ticket saved to Apple or Google Wallet sits on the phone until you revoke it, and the content on it can change weeks after the message that carried the save link scrolled out of the thread. Devotel Orbit now treats that artifact as a first-class outbound channel: the Wallet Passes surface lives in the Outbound hub next to your messaging destinations, and every pass you issue lands on the same contact and ledger the rest of your outreach reads.
Everything below describes the shipped surface — the wallet-passes resource guide covers the strategy side; this post covers what shipped and how the pieces join up.
Where passes land on the channel stack
The channel split is per-goal, and a wallet pass answers a goal none of the messaging channels own:
- SMS, WhatsApp, RCS, email — deliver the announcement, the campaign, the conversation.
- Voice and AI agents — handle the inbound ask or the outbound call cadence.
- Wallet passes — hold the durable credential: the loyalty card with its live points balance, the coupon with its redemption barcode, the ticket that scans at the gate.
The messaging channels stay load-bearing: every pass issues with a save link, and any channel that carries a link — SMS, WhatsApp, email, or an RCS card action — delivers it. The pass is what those channels hand over. Voice and messaging move the customer; the wallet is where what you gave them lives.
The capability that shipped
The Wallet Passes API covers the full lifecycle of a pass behind /api/v1/wallet-passes:
GET /platforms— reports whether Apple and Google Wallet credentials are connected, and which pass types and barcode formats your issuance form can offer. Passes issued before credentials are connected start producing working save links the moment they're connected — no re-issue needed.POST /issue— creates a loyalty card, coupon, or event ticket in one call and returns both platform payloads: the Apple Wallet pass structure and a signed Google Wallet "Save to Wallet" link. Issuing is idempotent, so a retried request never mints a duplicate pass.GET /(withGET /:id) — lists issued passes and reads a single pass's current state plus freshly minted save links.POST /:id/update— patches points, tier, seat, or expiry on an active pass; each update signals the holder's phone to refresh. Updates are partial — send only the fields that change.POST /:id/void— permanently revokes a pass; it renders as expired in the wallet and stays visible for audit.
Operators do the same from the dashboard without touching the API. The issuance surface sits at Outbound → Wallet passes (with the canonical Marketing URL still live), running on the same ledger the API reads, gated to owner, admin, and developer roles.
Passes tied to the contact, not the channel
A pass on Orbit issues against a contact, the way a message send does. Because outbound messaging, the inbox, and the native customer-data platform all resolve to the same contact record, the pass lifecycle joins the omnichannel timeline:
- The save link goes out over the channel the customer opted into — the delivery step is a normal message send with consent and suppression filtering applied like everything else.
- When the loyalty balance or coupon expiry changes,
POST /:id/updatedrives the on-phone refresh, and a follow-up SMS or WhatsApp note announcing the change comes from the same account with the same opt-out record. - In the customer-data platform and on Customer 360, the pass appears as an attached artifact on the contact's engagement history — visible to an agent mid-conversation, not trapped in a loyalty vendor's silo.
That single-contact resolution is the part a bolt-on loyalty or ticketing vendor can't give you: one opt-out, one consent record, one timeline across the pipe that delivers the pass and every follow-up about it.
Use cases
Three pass types cover the practical formats, each with its choice of QR, PDF417, Aztec, or Code 128 barcode:
Loyalty cards. Issue a membership card at enrollment — from an inbound AI agent, a point-of-sale trigger, or the enrollment flow itself — with the save link sent on the customer's preferred messaging channel. Points and tier updates push to the phone as they post; campaign sends announce the change with the ledger view agreeing on the number.
Coupons. A coupon pass carries the offer, an optional expiry, and the barcode the point-of-sale scans. Campaigns deliver the save link; when the expiry moves or the redemption posts, the wallet copy refreshes. Because issue is idempotent, a burst campaign that retries on a provider timeout never double-issues a coupon.
Event tickets. Tickets carry the seat, gate, or order identifier and the barcode the gate scanner reads. When the assignment changes — a re-seating, a gate move — the update endpoint patches the pass and the phone refreshes, rather than sending a replacement ticket.
Where to go next
- The strategy side: Wallet pass in Omnichannel Engagement — Loyalty Cards, Coupons, Tickets — where a pass fits next to SMS and RCS.
- The console: Outbound → Wallet passes to issue, update, and void from the dashboard.
- The reference: the wallet passes channel docs field-by-field.
Frequently asked questions
What is a wallet pass?
A wallet pass is a digital card — a loyalty card, coupon, or event ticket — saved to the Apple Wallet or Google Wallet app built into the phone. Unlike a message, it persists on the device until revoked or expired, and its content can be updated after it's saved.
How do customers receive the pass?
Every issued pass comes with a save link. Deliver it through the channel the customer opted into — SMS, WhatsApp, email, or an RCS card action — and one tap adds the pass. Orbit issues the link and sends the message from the same account.
Can a pass be updated after it's saved?
Yes. An update to an active pass (points, tier, seat assignment, coupon expiry) signals the holder's phone to refresh, without a re-send.
Do I need Apple and Google credentials connected before issuing?
No. Issue and manage passes before either platform is connected — the content is stored and readable, and working save links appear without re-issuing the moment the credentials connect. GET /platforms reports the current status.
Can operators issue passes without the API?
Yes. The dashboard issuance builder under Outbound → Wallet passes issues, updates, and voids passes and copies save links, on the same ledger the API reads, for owner, admin, and developer roles.
Published 27 August 2026.