> 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/developers-guides/integration-guides/wallet/enrolment-flows.md).

# Enrolment flows

## Enrolment flows

An enrolment flow is the moment a pass is created and linked to a real customer or business record. This is where external identifiers are attached to the pass for the first time. That step matters because later renders depend on those identifiers to fetch live data from source systems.

Enrolment is not a later synchronization step. The pass is created during the flow itself, then the wallet artifact can be built from that new pass record. If identifiers are missing or incorrect at enrolment time, connector-driven data will be missing on later renders.

<details>

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

* A loyalty signup flow creates a pass after a customer account is created in a CRM.
* A ticket purchase flow creates a pass after checkout and attaches the ticket ID.
* A membership renewal flow creates a replacement pass and links it to the existing customer record.

</details>

### What an enrolment flow does

An enrolment flow creates a pass and attaches the minimum data needed for future renders.

In practice, that usually means:

1. A source system or frontend flow identifies the customer or transaction.
2. The flow creates a pass or triggers pass creation.
3. External identifiers are attached to the pass at creation time.
4. The pass can then be rendered for wallet installation.

The pass record created during enrolment is intentionally thin. It stores identifiers, optional additional data, and internal platform fields. Source data stays in upstream systems.

If the pass data model needs a refresher, start with [Pass data and sync](/developers-guides/pass-architecture/pass-data-and-sync.md).

### Common enrolment patterns

#### Cinto SDK flow

The Cinto SDK is the main option when a custom web or app flow needs to create passes directly during enrolment.

This pattern is common when a frontend already controls signup, checkout, registration, or profile completion. The SDK creates the pass as part of that flow and provides the external identifiers needed later by connectors.

Use the [Cinto SDK documentation](https://docs.thewalletcrew.io/guides-enrolment/enrolment/on-your-website#npm-module) for the implementation flow.

#### Backend-driven enrolment (custom API)

Use this pattern when a backend creates the customer, order, membership, or ticket record. The external identifiers must exist in that backend before pass creation.

Call `POST /passes` with those identifiers to create the pass. See [Pass lifecycle → Creating a pass](/developers-guides/integration-guides/wallet/pass-lifecycle.md).

Build the resulting delivery URL with a signed external identifier. See [Pass delivery URLs](https://docs.thewalletcrew.io/guides-enrolment/enrolment/download-pages).

#### Built-in enrolment form

The platform also includes a built-in enrolment form with a pass step.

This pattern is useful when the project wants a hosted enrolment flow rather than a fully custom implementation. The same rule still applies: the pass is created during the flow, and identifiers must be available at that moment.

{% hint style="info" %}
This page focuses on the creation moment and the required identifiers. UI configuration details can be documented separately when needed.
{% endhint %}

#### Source-driven creation

Some projects create passes from a source-side event rather than from a user-facing form. In that model, an external system event triggers pass creation and the customer installs the pass later.

This pattern is covered in [Connector-triggered pass creation](/developers-guides/integration-guides/wallet/connector-triggered-pass-creation.md).

### What must exist at creation time

The most important input at enrolment time is the set of external identifiers.

Without them, connectors cannot locate the correct customer, order, membership, or ticket record during later renders. A pass can exist without useful identifiers, but it will behave like an isolated record with no reliable way to fetch source data.

Additional data can also be set at creation time when a value must live on the pass itself. This is useful for pass-level overrides or values that do not exist in any source system.

Use the [Cinto SDK documentation](https://docs.thewalletcrew.io/guides-enrolment/enrolment/on-your-website#npm-module) for implementation details when the flow creates passes directly, and use [Pass data and sync](/developers-guides/pass-architecture/pass-data-and-sync.md) for how identifiers and additional data are used later.

### What happens after enrolment

Creating the pass does not create a background link that keeps wallet content fresh automatically.

After enrolment, wallet content changes only when a render trigger happens, such as installation, preview, or push update. Each render fetches live connector data again using the identifiers stored during enrolment.

Use [Getting started with the API](/developers-guides/integration-guides/getting-started-with-the-api.md) for the first tenant-scoped update calls after a pass already exists.

### Validation checklist

A valid enrolment flow should confirm three things.

* The pass is created successfully.
* The expected external identifiers exist on the pass.
* A later render can retrieve source data using those identifiers.

A fast validation pattern is to create a test pass, inspect the identifiers in the back-office, then trigger a render or push update and confirm that connector-backed fields resolve correctly.

### FAQ

<details>

<summary><strong>Can external identifiers be attached later if they were missing at enrolment time?</strong></summary>

They should be treated as creation-time data. A flow is more reliable when identifiers are correct at the moment the pass is created.

</details>

<details>

<summary><strong>Does enrolment store customer data inside The Wallet Crew?</strong></summary>

No. Enrolment creates the pass record and stores the identifiers and any pass-level values that must persist. Customer data remains in source systems.

</details>

<details>

<summary><strong>Does pass creation automatically refresh wallet content later?</strong></summary>

No. Later refreshes still depend on a render trigger such as installation, preview, or push update.

</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/developers-guides/integration-guides/wallet/enrolment-flows.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.