01
Apple signing
Pass Type IDs, signing certificates, provisioning, and renewal all need an owner.
walletKit issues, updates, and verifies Apple Wallet and Google Wallet passes from one API. Built for platforms that already own the member relationship.
Your platform remains the system of record for members, billing, subscriptions, and events.
const res = await fetch(API_URL + "/passes/upsert", {
method: "POST",
headers: {
"X-API-KEY": process.env.WALLETKIT_API_KEY,
"Content-Type": "application/json"
},
body: JSON.stringify({
externalUserId: "sub_2481",
templateId: process.env.WALLETKIT_TEMPLATE_ID,
wallets: ["apple", "google"]
})
});
const { data: pass } = await res.json();
return pass.links;https://passes.yourplatform.com/p/ps_92kq
Why embed
Operating passes across two wallet platforms is an ongoing infrastructure job. It is rarely the product your customers pay you to build.
01
Pass Type IDs, signing certificates, provisioning, and renewal all need an owner.
02
Apple device registration, update tags, APNs, and delivery failures form a second system.
03
Classes, objects, service accounts, JWT claims, and callbacks use a different model.
04
Expired, paused, revoked, and reinstated passes must stay in step with your records.
One pass lifecycle
Your records remain the source of truth. walletKit handles the credential that mirrors them.
Node.js and Python quickstartPOST /passes/upsert
Create a pass from a template, keyed to your own member ID. Hand back install links for Apple Wallet and Google Wallet.
links.apple · links.googlePATCH /passes/{id}
Change tier, dates, balance, or status when the source record changes. The credential stays current without a new download.
{ "status": "paused" }GET /passes/{id}
Every pass QR resolves to its live record, so a scan always shows current status. Signed webhooks report installs, expiries, and points back to your platform.
webhook · pass.installedYour product
You do not adopt another CRM or billing model. A pass is a projection of the records and states your platform already stores.
Every tier becomes one pass. Change status on your side and the lock screen updates within seconds — no reinstall, no new download link.
A single booking with five tickets issues five separate passes — one per attendee, each independently scannable at the door.
Verify from a phone browser and post the result back to the event record you already own.
Agentic Pass through MCP
Agentic Pass is walletKit's delegated-authority layer. Your assistant connects through MCP, but every pass or reward action remains bound to a signed mandate from the human member.
Cap spend, quantity, purpose, pass type, and lifetime when the mandate is issued.
Allow small actions automatically and route larger ones back to the member for approval.
Remove the agent’s authority without changing the member account or pass.
Record every allow, escalate, deny, and error decision for later review.
White label
walletKit is infrastructure. Your customers stay inside your product, under your brand, with your team as their point of contact.
passes.yourplatform.com
scan.yourplatform.com
Serve install and scan flows from a subdomain your customers recognise.
Use your product and customer identity without a walletKit watermark.
Package pass access inside the plans and commercial model you already sell.
Keep the customer relationship while walletKit supplies the credential audit trail.
Customer zero
The first integration maps member records, subscriptions, group bookings, guest passes, and event attendance onto the walletKit pass lifecycle.
The platform keeps its members, billing, campaigns, and leads. walletKit handles the phone credential and returns verification events.
Request API access
Tell us what your platform already manages and where a wallet credential should fit. We will map the integration with you.
hello@walletkit.app
security@walletkit.app