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.

Your wallet data belongs to you. The Wallet Crew emits every pass event in real time — you decide where it goes and what you do 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.

Make sure each pass includes 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

If you want real time updates, use webhooks or a custom connector.

If you prefer batch jobs or backfills, use the Pass API.

If you mainly need counts and trends, use Insights API.

Start with Insights API for aggregate analysis

If 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 inside The Wallet Crew, compare Statistics and Report.

Decide what to sync into your tools

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.

You usually want an overall field, plus per-wallet fields. That lets you segment 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 your stack

Your 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 your endpoint as they happen. Subscribe to Pass:Installed and Pass:Uninstalled.

Next step: configure your webhook endpoint and validate signatures.

See Listen to The Wallet Crew event using webhook.

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 Custom Connector to call API when pass installation status change.

Option 3 — Pass API (batch sync + backfills)

Use the Pass API when you want 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 your 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 your stack

Use webhooks for most setups. Use a custom connector if you need a different payload.

3

3) Update fields and segments in your 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

If you do not see events, start with signature validation. Then check endpoint availability and retry handling.

If you see duplicates, add idempotency in the downstream write path. Use the most recent timestamp as the tie-breaker.

If you cannot match events to customers, you are missing an identifier. 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.