Send wallet events to your tools

Send wallet install, uninstall, scan, and notification events to CRM, CDP, BI, and data warehouse tools with webhooks, custom connectors, the Pass API, or the Insights API.

The Wallet Crew does not lock data inside the platform. Every event emitted across a wallet programme can be sent to a CRM, CDP, BI tool, or data warehouse. Four integration paths cover most needs: webhooks, a custom connector, the Pass API, and the Insights API.

Wallet data belongs to the brand. The Wallet Crew emits every pass event in real time, and the brand decides where it goes and what is done with it.

Real-world examples

• A CRM or CDP team sends Pass:Installed events into Braze or Salesforce to trigger onboarding journeys after wallet adoption.

• A BI team streams wallet events into BigQuery or Snowflake, then uses the Insights API to monitor weekly installs by Medium, Tag, or Host.

• An ecommerce team keeps real-time install status in its stack with webhooks, then uses a daily Pass API backfill to repair drift after outages.

What “installation status” means

Installation status is a lifecycle signal emitted when a user adds or removes a pass. It covers installs and removals on Apple Wallet and Google Wallet, and each wallet can change state independently.

This matters because install state is wallet-specific. The same customer can install a pass on Apple Wallet, Google Wallet, or both, and each removal event must be interpreted in that context.

Every pass should include a stable external identifier, such as customerId or email. That identifier is used to reconcile events with records in the rest of the stack.

Choose the right sync method

For real-time updates, use webhooks or a custom connector.

For batch jobs or backfills, use the Pass API.

When only counts and trends are needed, use the Insights API.

Start with Insights API for aggregate analysis

When there is no need for per-customer sync and the goal is to query trends and aggregate data, start with the Insights API. It is the fastest path to questions such as “how many passes were installed this week by medium?”

Use Insights when counts, trends, and grouped analysis matter more than record-level updates. Query events such as Pass:Installed and Pass:Uninstalled with KQL.

Next step: set up authentication and run a first query.

See Insights API.

For aggregate analysis in the back office, use Analytics dashboards. For pass-level records, use Report.

Decide what to sync into the stack

Start by defining the “truth” the stack should store. Most teams keep both a simple status and a few timestamps in the CRM or CDP.

An overall field plus per-wallet fields usually works best. That allows segmentation without losing detail.

Common fields:

• walletStatus: none, apple, google, both

• appleWalletInstalledAt: timestamp, optional

• googleWalletInstalledAt: timestamp, optional

• walletLastChangedAt: timestamp

• walletLastEvent: installed or uninstalled

Treat events as at-least-once delivery. Expect duplicates and out-of-order delivery.

Reconcile events to records in the stack

The sync needs a join key. Use a stable external identifier stored on the pass.

Good identifiers are customerId, accountId, or a normalized email. Avoid identifiers that can change frequently.

When an event arrives, resolve it to one record in the stack. Then update the per-wallet flags and the overall status kept in the stack.

Understand the edge cases

Installation is wallet-specific. A single customer can install on Apple and Google.

Uninstall also stays wallet-specific. An Apple uninstall does not imply Google uninstall.

Some customers reinstall quickly. Use timestamps to avoid status flapping in downstream tools.

Option 1 — Webhooks (real time, lowest effort)

Webhooks push events to a receiving endpoint as they happen. Subscribe to Pass:Installed and Pass:Uninstalled.

Next step: configure the webhook endpoint and validate signatures.

See Webhooks.

Option 2 — Custom connector (real time, custom payload)

Use a custom connector when the default webhook payload is not enough.

It’s the right choice for custom payload shapes. It’s also useful for custom auth (API key, OAuth) or extra logic.

Typical logic includes routing, enrichment, throttling, and retries.

Next step: implement OnPassInstalled and OnPassUninstalled.

See Pass installation and uninstallation hooks.

Option 3 — Pass API (batch sync + backfills)

Use the Pass API to periodically sync installation state.

This is also the best choice for rebuilding state in downstream tools after downtime.

Start from the API reference. Look for pass list endpoints that can be filtered by installation status.

Backfill pattern that works well

Run a scheduled job that recomputes source-of-truth status from the Pass API. Most teams run it daily.

Use real-time events for speed. Use the backfill for consistency.

If the stack and passes disagree, trust the Pass API. Then repair the downstream record and keep going.

A pragmatic end-to-end workflow

1

1) Add a stable identifier to every pass

Pick one identifier. Use the same field on every pass.

2

2) Send real-time events to the stack

Use webhooks for most setups. Use a custom connector when a different payload is needed.

3

3) Update fields and segments in downstream tools

Update per-wallet flags and timestamps. Recompute the overall walletStatus.

4

4) Backfill regularly

Schedule a Pass API job. Use it to repair drift and cover downtime.

5

5) Track adoption with Insights

Use Insights for trends and monitoring. Validate that installs and uninstalls match expectations.

Troubleshooting

When no events arrive, start with signature validation. Then check endpoint availability and retry handling.

When duplicates appear, add idempotency in the downstream write path. Use the most recent timestamp as the tie-breaker.

When events cannot be matched to customers, an identifier is missing. Add it to the pass data, then backfill to repair history.

FAQ

Which option should be used first?

Start with the Insights API when only aggregate trends matter. Start with webhooks when events need to reach a CRM, CDP, or automation tool in real time. Add the Pass API when a reliable backfill is also needed.

Why are both real-time events and a batch backfill often used together?

Real-time delivery keeps journeys, alerts, and segments fresh. A scheduled Pass API backfill repairs drift caused by retries, outages, or temporary downstream failures.

Why is a stable identifier mandatory?

Wallet events are only useful downstream when they can be matched to the correct record. A stable identifier, such as customerId or a normalized email, makes reconciliation reliable across webhooks, connectors, and batch jobs.

Can the same customer appear as installed on both Apple and Google?

Yes. Installation is wallet-specific. The same customer can hold the same pass in Apple Wallet and Google Wallet, so downstream models should keep per-wallet fields as well as an overall status.