How to Send a Wallet Pass to 10,000 Customers at Once: A Guide to Bulk Distribution

Sending a wallet pass to a single customer is simple. Sending one to 10,000 customers is a different engineering challenge entirely — and it is one that catches many teams off guard the first time they attempt it. The core problem is that wallet passes are deeply personalised: every pass has a unique serial number, the customer's name, a unique barcode value and potentially unique field data. There is no such thing as a “broadcast pass” that gets sent to everyone. Each one must be generated individually and distributed to the right person.

This guide covers the three main approaches to bulk distribution, the rate-limiting constraints you need to understand and how to structure a bulk send that completes reliably without being flagged as spam or throttled by Apple.

Why each pass must be unique

Before getting into methods, it is worth understanding why bulk distribution is inherently different from bulk email. When you send a marketing email to 10,000 subscribers, you might personalise the salutation and that is roughly it. The email itself is the same file sent repeatedly.

A wallet pass is more like a signed certificate. Apple Wallet requires every pass to have a unique serial number within its pass type. The barcode value — used for scanning at the till or event gate — must be unique so it maps to the correct customer record in your system. The customer's name, membership tier and any other personalised fields are embedded in the pass bundle itself. Finally, the entire pass bundle is cryptographically signed with your Pass Type ID certificate. That signature is generated freshly for each pass.

This means that issuing 10,000 passes requires 10,000 signing operations, 10,000 unique bundles and 10,000 distribution events. The question is how to orchestrate that efficiently.

Option 1: CSV upload

The simplest approach for non-technical teams is a CSV upload. You export your customer list from your CRM, spreadsheet or ecommerce platform — including columns for the fields your pass needs, such as name, email, membership tier and a unique identifier — and upload it directly to the pass management platform.

The platform reads each row, generates a personalised pass for each customer, and then emails each customer their individual pass link. The generation and distribution happen in the background, typically within minutes for lists up to 10,000 rows. For larger lists, batch processing may take longer but the result is the same.

CSV upload is the right choice when you have a clean customer list, a straightforward pass template and no need for programmatic control. It requires no API integration and can be done by anyone with access to the dashboard.

The main limitation is flexibility. If you need to apply conditional logic — issuing Gold tier passes to some customers and Silver to others based on calculated data — you either need to pre-process the CSV to include those values, or you need the API approach below.

Option 2: API batch endpoint

For technical teams, the batch API approach gives you full programmatic control. Rather than creating passes one by one via individual POST requests, a batch endpoint accepts an array of pass objects in a single request body. The platform processes the array asynchronously, generating each pass in parallel, and returns a job ID you can poll or receive a webhook for when the batch completes.

The batch API is the right choice when pass data is being generated programmatically — computed points totals, dynamic expiry dates, segmented content — or when you need the distribution to trigger automatically as part of a larger workflow without human involvement.

When building against a batch API, structure your batches sensibly. Submitting 10,000 passes as a single array works, but breaking into batches of 500–1,000 gives you more granular error handling. If one record in the batch has a validation error, a smaller batch means fewer passes affected by a retry.

Option 3: CRM export and webhook trigger

Many pass programmes live alongside a CRM — HubSpot, Salesforce, Klaviyo or a similar platform holds the customer data and segment logic. In this setup, you export a segment from your CRM and trigger pass creation via webhook or a Zapier zap for each record in the segment.

This approach works well for ongoing distribution. Rather than a one-time bulk send, you set up an automation: when a contact moves into a segment (e.g. “loyalty programme members”), a webhook fires automatically to Issuepass and creates their pass. The bulk send then becomes an operation you run once to backfill existing members, and the automation handles all future enrolments in real time.

The CRM integration approach is particularly useful when pass distribution is tied to a business event — a new product launch, a seasonal campaign, a post-purchase sequence — that is already managed in the CRM.

Rate limiting and delivery considerations

Apple Push Notification Service (APNS) limits. When you issue 10,000 passes and each customer adds their pass, APNS receives 10,000 device registration calls over a short period. This is fine. The concern arises when you then push a notification to all 10,000 devices simultaneously — Apple's push infrastructure has per-pass-type rate limits. In practice, for most business-scale deployments, these limits are generous enough not to be a concern. If you are distributing at very large scale (100,000+ passes), spread push sends over time rather than firing all at once.

Email delivery rates. When distributing passes via email, sending 10,000 emails in one burst can trigger spam filters at many mail providers. Best practice is to send in batches of 200–500 per hour. This is not a technical limitation of the pass platform — it is a deliverability best practice for any bulk email send. Use a reputable email sending service (AWS SES, SendGrid, Postmark) and warm up your sending domain before a large send if it is your first significant bulk operation.

Pass generation throughput. Generating 10,000 signed pass bundles simultaneously is computationally intensive. A well-architected pass platform queues generation jobs and processes them in parallel workers, completing a 10,000-pass batch within a few minutes. If your platform processes them sequentially, a 10,000-pass batch could take hours. Check how your platform handles batch generation before committing to a large send deadline.

Background pass adding (WWDC 2025)

Apple introduced a new PKPassLibrary API at WWDC 2025 that allows verified apps to add passes to a user's wallet in the background, without requiring the user to tap “Add to Wallet.” This applies to first-party apps that have been granted permission by Apple for specific pass types — primarily transport and identity credentials.

For most business use cases — loyalty cards, membership passes, event tickets — this API is not yet available to third-party developers. The standard flow of emailing a pass link and having the customer tap “Add to Wallet” remains the correct distribution approach. The background add capability is worth watching as Apple extends it.

How Issuepass handles bulk distribution

Issuepass supports all three distribution methods described above. CSV upload is available directly in the dashboard — upload your file, map the columns to your pass template fields and click Send. The platform generates and emails all passes asynchronously, with a progress indicator in the dashboard.

The batch API endpoint accepts arrays of pass objects and processes them in parallel across our Cloudflare Workers infrastructure. Large batches are queued, and a webhook fires to your endpoint when all passes in the batch have been generated and distributed. Delivery tracking is available per-pass: you can see which customers have added their pass, which emails bounced and which passes are still pending.

Ready to run your first bulk pass send? Start free and issue passes to your whole customer list today.