> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/guides-monitoring/monitor/sync-pass-installation-status-to-your-crm.md).

# Send wallet events to your tools

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

{% hint style="info" %}
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.
{% endhint %}

<details>

<summary><strong>Real-world examples</strong></summary>

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

</details>

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

{% hint style="info" %}
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.
{% 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**.

### 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](https://github.com/TheWalletCrew/docs/blob/main/guides/develop/guides/insights-api.md).

For aggregate analysis inside The Wallet Crew, compare [Statistics](broken://spaces/EsokFUBfsbM9mlwavmMB/pages/OHbNFPmU45yCLxKLUbY9) and [Report](/guides-monitoring/monitor/report.md).

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

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

### 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](https://github.com/TheWalletCrew/docs/blob/main/guides/develop/guides/webhook.md).

### 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://github.com/TheWalletCrew/docs/blob/main/guides/connect/custom-connector/installation-changed-extensibility.md).

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

{% 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 fields and segments in your tools

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 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

<details>

<summary>Which option should be used first?</summary>

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.

</details>

<details>

<summary>Why are both real-time events and a batch backfill often used together?</summary>

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

</details>

<details>

<summary>Why is a stable identifier mandatory?</summary>

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.

</details>

<details>

<summary>Can the same customer appear as installed on both Apple and Google?</summary>

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.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.thewalletcrew.io/guides-monitoring/monitor/sync-pass-installation-status-to-your-crm.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.