# Sync pass installation status to your CRM

## Sync pass installation status to your CRM

Track whether a pass is installed in **Apple Wallet** or **Google Wallet**. Then sync that signal to your CRM, CDP, or marketing tools.

### What “installation status” means

Installation status is a lifecycle signal emitted when a user adds or removes a pass. It covers four states.

It can be installed on Apple. It can be installed on Google. It can be uninstalled from Apple. It can be uninstalled from Google.

{% hint style="info" %}
Make sure each pass includes a stable external identifier (for example `customerId` or `email`). You will use it to reconcile events with records in your CRM.
{% endhint %}

### 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**.

### Decide what you want to sync

Start by picking the “truth” you want in your CRM. Most teams store both a simple status and a few timestamps.

You usually want an overall field, plus per-wallet fields. That lets you segment without losing detail.

Common CRM fields:

* `walletStatus`: `none`, `apple`, `google`, `both`
* `appleWalletInstalledAt`: timestamp, optional
* `googleWalletInstalledAt`: timestamp, optional
* `walletLastChangedAt`: timestamp
* `walletLastEvent`: installed or uninstalled

{% hint style="warning" %}
Treat events as **at-least-once delivery**. Expect duplicates and out-of-order delivery.
{% endhint %}

### Reconcile events to CRM records

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 CRM record. Then update the per-wallet flags and your overall status.

### 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 “flapping” in your CRM.

### 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](https://docs.thewalletcrew.io/develop/guides/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](https://docs.thewalletcrew.io/connect/custom-connector/installation-changed-extensibility).

### 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 your CRM state after downtime.

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

Swagger: <https://admin.thewalletcrew.io/api/swagger/index.html>

#### Backfill pattern that works well

Run a scheduled job that recomputes CRM truth from the Pass API. Most teams run it daily.

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

If your CRM and passes disagree, trust the Pass API. Then fix the CRM record and keep going.

### Option 4 — Insights API (analytics / BI)

Use Insights when you want counts and trends, not per-customer sync. Query events like `Pass:Installed` and `Pass:Uninstalled` with KQL.

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

See [Insights API](https://docs.thewalletcrew.io/develop/guides/insights-api).

### A pragmatic end-to-end workflow

{% stepper %}
{% step %}

### 1) Add a stable identifier to every pass

Pick one identifier. Use the same field on every pass.
{% endstep %}

{% step %}

### 2) Send real-time events to your stack

Use webhooks for most setups. Use a custom connector if you need a different payload.
{% endstep %}

{% step %}

### 3) Update CRM fields and segments

Update per-wallet flags and timestamps. Recompute the overall `walletStatus`.
{% endstep %}

{% step %}

### 4) Backfill regularly

Schedule a Pass API job. Use it to repair drift and cover downtime.
{% endstep %}

{% step %}

### 5) Track adoption with Insights

Use Insights for trends and monitoring. Validate that installs and uninstalls match expectations.
{% endstep %}
{% endstepper %}

### 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 your CRM write path. Use the most recent timestamp as your 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.