> 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/connector-triggered-pass-creation.md).
# Connector-triggered pass creation
## Connector-triggered pass creation
Some integrations create passes automatically from source-system events. Instead of a frontend or SDK creating the pass during a user-facing enrolment flow, the connector creates the pass when a relevant event happens in the upstream system.
This pattern is useful when the source system is already the system of record for eligibility or lifecycle events. The key rule stays the same: the pass must be created with the correct external identifiers, because later renders depend on those identifiers to fetch live data.
Real-world examples
* A CRM event creates a loyalty pass when a customer joins a program.
* A ticketing event creates a pass when an order is confirmed.
* A membership system creates a pass when an active subscription starts.
### When this pattern is used
Connector-triggered creation is the right pattern when pass issuance should follow a system event rather than a user action in a custom frontend.
Common examples are customer creation, order confirmation, subscription activation, or another upstream event that proves a pass should exist. Once the pass is created, distribution and installation can happen later through the project's chosen channel.
If the project needs a user-facing creation flow instead, use [Enrolment flows](/developers-guides/integration-guides/wallet/enrolment-flows.md).
### What the connector must provide
At creation time, the connector must provide the identifiers needed for later lookups.
These external identifiers are the durable link between the pass and the source record. Without them, later renders cannot fetch customer or transaction data reliably.
The connector can also set pass-level values such as additional data when the project requires stored overrides that do not come from a live connector lookup.
Use [Pass data and sync](/developers-guides/pass-architecture/pass-data-and-sync.md) for the data model behind this flow.
### What happens after creation
Once the connector creates the pass, the rest of the lifecycle follows the same model as any other pass.
The platform does not copy source data into long-term storage and keep it synchronized in the background. Later renders still fetch live data from source systems. If source data changes, a render trigger is still required before the installed pass changes.
Common triggers are wallet installation, preview, and push update.
Use [How a pass is rendered](/developers-guides/pass-architecture/how-a-pass-is-rendered.md) for the full render pipeline and [Getting started with the API](/developers-guides/integration-guides/getting-started-with-the-api.md) for API-driven updates after creation.
### Operational implications
This creation model changes where errors usually appear.
If a pass is not created, the first place to inspect is the upstream event and the connector path that handles it. If the pass exists but later renders show blank fields, the first place to inspect is the external identifiers stored on the pass.
{% hint style="warning" %}
Creating a pass from a connector event does not guarantee that later connector lookups will succeed. Pass creation and later render-time data fetches depend on the right identifiers being stored on the pass.
{% endhint %}
### Compare the creation patterns
#### Connector-triggered creation
A system event creates the pass automatically. This works well when the source system already decides who should receive a pass.
#### Enrolment flow creation
A frontend or hosted flow creates the pass during a user-facing journey. This works well when the project controls signup, registration, or checkout directly.
In both patterns, the API is used after creation for updates, notifications, scans, and other lifecycle operations. Use [Getting started with the API](/developers-guides/integration-guides/getting-started-with-the-api.md) for those management calls.
### Validation checklist
A connector-triggered creation flow should confirm four things.
* The expected source event occurs.
* The pass is created exactly once for that event.
* The correct external identifiers are stored on the new pass.
* A later render can fetch source data successfully.
Webhooks are often useful here because they make it easier to observe pass lifecycle events such as pass creation and installation.
Use [Webhooks](/developers-guides/integration-guides/webhooks.md) when lifecycle visibility is needed.
### FAQ
Does connector-triggered creation store customer data inside The Wallet Crew?
No. It creates a pass record and stores the identifiers and any pass-level values that must persist. Customer data remains in source systems.
Can a connector both create a pass and later supply render-time data?
Yes. Those are separate moments in the lifecycle. Creation establishes the pass and identifiers. Later renders fetch live data again.
Is this pattern better than a Cinto SDK flow?
Neither pattern is universally better. The right choice depends on where the issuance decision lives and which system controls the user journey.
---
# 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/connector-triggered-pass-creation.md?ask=&goal=
```
`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.