Connector-triggered pass creation
Understand when connectors create passes automatically and which data must exist for later renders.
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.
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 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 for the full render pipeline and Getting started with the API 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.
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.
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 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 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.
Last updated