Distribution
Deliver Aparté tickets to Apple Wallet and Google Wallet from email journeys or owned web pages.
Why distribution matters
A wallet ticket is useful only if the entry point is easy to open and safe to trust. Aparté distribution usually starts right after purchase, on the confirmation page, in the confirmation email, or later from an account page.
The Wallet Crew supports two practical patterns. One pattern uses hosted ticket pages. The other uses the SDK on a website controlled by the Brand or partner.
Real-world examples
Confirmation email: one hosted link opens the ticket list for the booking.
My tickets page: one SDK button appears next to each ticket row.
Reminder journey: the same hosted link is reused before the event.
Send tickets from an email
Email is the most common Aparté distribution channel. It works well when the ticketing flow already sends a purchase or reminder email.
The Wallet Crew exposes hosted pages that detect the device and open the right wallet flow. On mobile, the page shows the native Apple Wallet or Google Wallet action. On desktop, it falls back to a QR code.
Always use a custom domain for these links. This keeps the organizer branding visible and avoids exposing a generic Wallet Crew domain to customers.
For the full email pattern, see Via email.
Link to multiple tickets
Use the hosted tickets page when one Aparté order item resolves several tickets.
https://<customdomain>/<tenantId>/tickets?ids.aparte.orderItemId=<orderItemId>&ids.aparte.orderItemId.hmac=<hmac>ids.aparte.orderItemId is the multi-ticket identifier. The matching HMAC signs that exact value.
This page lists every ticket resolved from that Aparté order item. It is the standard entry point for an order confirmation journey when several tickets must be exposed from one booking flow.
A QA example follows the same structure:
Link to a single ticket
Use the hosted ticket page when the journey must open one precise ticket directly.
id.aparte.ticketId is the single-ticket identifier. Its value is <orderItemId>|<seatId>.
Encoding the separator as %7C is safer than leaving a raw | in the URL. The HMAC must match the exact value used in the link.
A QA example follows the same pattern:
Email implementation notes
Three rules matter for reliability. Compute the HMAC server-side. Always use a configured custom domain, not localhost. Preserve the full URL in the email tool so no query parameter is truncated or rewritten.
Add the button on a website with the SDK
Use the SDK when the Brand or partner controls the page where the ticket is shown. Typical placements are an order confirmation page, a customer account, or a dedicated ticket list.
The SDK handles device detection and renders the right wallet action. The Aparté-specific part is the identifier contract sent to the SDK.
For the full website integration model, see On your website.
Single-ticket SDK pattern
For one ticket, the page should resolve the Aparté identifier in the same format as the hosted single-ticket URL.
Use aparte.ticketId as the external identifier. Its value is <orderItemId>|<seatId>. The matching HMAC must be generated server-side from that exact value.
This is the pattern to use when one wallet button is rendered for one ticket card or one ticket row.
Multi-ticket website pattern
For a page that shows several tickets, two patterns work well.
The first pattern renders one SDK button per ticket. This is useful on an authenticated My tickets page.
The second pattern links to the hosted /tickets page using ids.aparte.orderItemId. This is usually simpler on a confirmation page because one link can expose the full ticket list resolved from the order item.
Security notes
Aparté distribution relies on signed identifiers. The HMAC must stay server-side and must never be generated in browser code.
The identifier value and the signed value must stay identical. If the ticket id is signed as <orderItemId>|<seatId>, the distributed URL must reuse that exact value. If the pipe is URL-encoded in the final link, the HMAC still signs the logical identifier value, not a different ticket id.
FAQ
What is the difference between id.aparte.ticketId and ids.aparte.orderItemId?
id.aparte.ticketId targets one precise ticket.
ids.aparte.orderItemId targets the hosted list flow and resolves the tickets attached to that Aparté order item.
Why should a custom domain always be used?
A custom domain keeps the organizer branding visible during the wallet journey.
This avoids exposing a generic The Wallet Crew domain to customers and creates a more consistent experience between the event, the email, and the hosted wallet page.
Can the same email link expose several tickets?
Yes.
Use the hosted /tickets page with ids.aparte.orderItemId and its matching HMAC.
When should the SDK be preferred over the hosted page?
Use the SDK when the page is fully controlled and the wallet action should appear inline.
Use the hosted page when email distribution or a single shared link is simpler.
What happens on desktop instead of mobile?
The hosted page detects the device automatically.
On mobile, it presents the native wallet action. On desktop, it falls back to a QR code so the pass can still be opened from a phone.
Should the HMAC be generated in the browser?
No.
The HMAC must always be generated server-side. Browser-side signing would expose the secret and weaken the distribution flow.
Last updated