Introduction
Integrating PassKit with your CRM, POS, loyalty platform, ticketing system, payment processor, or any backend system follows a consistent set of principles.
Whether you're using the API, SDKs, or no-code tools like Zapier or Make, a small amount of upfront planning will dramatically improve the success, scalability, and reliability of your implementation.
This guide will help you design your integration before you start building, so you can avoid rework and scale with confidence.
In Simple Terms
Your existing system remains the source of truth.
PassKit delivers that data to customers in real time via Apple Wallet and Google Wallet.
Example Used Throughout
To make this guide easier to follow, we’ll use a simple example:
Loyalty Program
Master System: CRM or loyalty database
External ID: membership number
Trigger: points earned
Pass update: points balance changes
The same principles apply to tickets, gift cards, memberships, and more.
Diagram: Recommended Integration Architecture
Your Master System (Source of Truth)
Your Master System is your organisation’s primary system of record.
Examples include:
CRM (Salesforce, HubSpot, Zoho)
POS (Square, Clover, Toast)
E-commerce (Shopify, WooCommerce)
Loyalty or rewards systems
Gift card / stored value systems
Ticketing or booking platforms
ERP / order management systems
PassKit does not replace these systems.
Instead, it acts as a customer-facing extension, displaying relevant data in a mobile wallet.
Key Principle
All data should originate from your Master System and flow into PassKit.
Business logic (such as points calculation, eligibility, balances, or status) should always remain in your Master System — not in PassKit.
Typical Integration Flow
A trigger occurs in your system
(e.g. signup, purchase, reward issued)Your system sends data to PassKit
(via API, SDK, or no-code platform)A pass is created or updated
The customer installs or receives an updated pass
Quick Start: Build Your First Pass (Recommended Path)
This is the fastest way to go from zero to a working pass.
This approach is ideal for proof-of-concepts and initial implementations:
Define your use case
(e.g. loyalty, coupon, stored value)Design your pass template in the PassKit Portal
Map your data fields from your system
Use Postman or QuickStart examples to issue your first passes
Install a pass on your device to understand real behaviour
Add update triggers from your system
Scale distribution (API, SmartPass, or automation)
Why This Approach Works
Leverages your existing systems
Avoids duplication of logic
Enables real-time updates
Scales to high-volume use cases
Keeps architecture clean and maintainable
Core Integration Planning
Data Mapping
Identify which fields from your system populate the pass:
Customer name
Membership ID
Points balance
Gift card value
Expiry dates
Order or booking details
👉 Create a simple mapping document before building.
Trigger Points
Define what events control the pass lifecycle.
Create:
Signup
Purchase
Enrolment
Update:
Points change
Balance update
Status change
Delete:
Cancellation
Expiry
Account closure
Integration Methods
SDKs (Strongly Recommended)
Fastest and most efficient option (built on gRPC / HTTP 2.0)
Strongly typed with code auto-completion
Handles connections, serialization, and complexity for you
Best for production and scalable systems
Reduces development time and lets your team focus on business logic instead of infrastructure
👉 If you are building your own integration, use the SDKs unless you have a specific reason not to.
Learn more: Why we recommend SDKs
Direct API
Lower-level integration approach
Typically used only for specialised or edge-case implementations
Requires more engineering effort (handling requests, retries, data formats)
No-Code Platforms (Zapier / Make)
Fastest way to get started
Suitable for simple workflows and PoCs
Requires monitoring, error handling, and maintenance at scale
Webhooks
PassKit can notify your system of key events:
pass issued
pass installed
pass updated
pass deleted
Used for:
analytics
engagement tracking
automation
External IDs (Critical Decision)
👉 Decision: Will you use Pass IDs or External IDs?
External IDs are identifiers from your system (e.g. membership number).
They allow you to:
update passes without storing PassKit IDs
align directly with your data model
Pass ID vs External ID
Both approaches are fully supported in production environments.
The choice depends on how you want to manage and reference passes within your system.
Option | Description |
Pass ID | Generated by PassKit. You store and use this ID to update or delete passes. |
External ID | Provided by your system (e.g. membership number). Lets you reference passes using your own identifiers. |
When to Use Each Approach
Use Pass ID if:
You’re happy to store and manage PassKit-generated IDs
Your system doesn’t already have a strong unique identifier
You want a simple, straightforward integration
Use External ID if:
You already have a stable unique identifier (e.g. membership number, order ID)
You want to align directly with your existing data model
You prefer not to manage PassKit IDs separately
In most integrations, External IDs provide a cleaner and more scalable way to align PassKit with your existing systems.
External ID Rules
Must be unique
Cannot be changed once set
Must be planned carefully before implementation
Pass Lifecycle (Essential Understanding)
A pass moves through these stages:
Issued → Installed → Updated → Expired/Deleted
Important: A pass is billable when it is issued — even if it is not installed or used.
Advanced Topics (For Technical / Enterprise Teams)
Data Flow Model
Recommended approach:
Master System → PassKit → Wallet
This ensures:
consistency
no data conflicts
real-time accuracy
Integration Architecture Options
Direct Integration
System → PassKit API
Middleware Layer
System → Middleware → PassKit
Useful for:
data transformation
orchestration
legacy systems
No-Code Platform Considerations
When using Zapier or Make:
Ensure your system is supported
Validate trigger availability
Carefully map data fields
Understand rate limits
Implement error handling
Maintain automations over time
Using Custom Images
Images must be publicly accessible.
Options:
PassKit Image Library (recommended)
Public CDN (e.g. AWS S3)
Public file links
Security
Ensure:
secure API authentication
encryption (in transit and at rest)
compliance (GDPR, CCPA)
regular audits
Detailed Pass Lifecycle (Advanced)
Creation (Issuance)
Triggered from your system
Data mapped and sent to PassKit
Pass ID returned and stored
Installation
User adds to wallet
Webhook available
Updates
Triggered from your system
Pushed via API or automation
Deletion
Triggered by business rules
Executed via API
Common Mistakes to Avoid
Treating PassKit as a source of truth
Not planning External IDs properly
Missing update triggers (passes become stale)
Not storing Pass IDs when needed
Not testing real wallet behaviour
Ignoring rate limits or error handling
Changing identifier strategy mid-project
Best Practices
Plan before building
Keep Master System in control
Keep business logic (e.g. points, eligibility, balances) in your Master System — not in PassKit
Implement logging and monitoring
Handle errors properly
Test edge cases
Design for scale
Enhancing Customer Engagement
Passes are a customer-facing layer — your main system still owns the full experience.
Consider adding:
links to account portals
loyalty dashboards
transaction history
This extends the value of your existing systems.
Summary
A successful PassKit integration follows one core principle:
Your system manages the data.
PassKit delivers that data to the customer in real time.
Final Thought
PassKit works best as a platform extension, not a standalone system.
With the right approach, you can turn your existing data into a real-time, always-accessible customer experience in the wallet.