This documentation is currently under development. Certain sections are not yet complete and will be added shortly.
For the complete documentation index, see llms.txt. This page is also available as Markdown.
GuideAPIIntegrationWalletDevelopers

The Wallet Crew API developer guide

Build Apple Wallet and Google Wallet pass integrations with The Wallet Crew API, including authentication, pass updates, webhooks, scans, and reporting.

The Wallet Crew API developer guide

Build Apple Wallet and Google Wallet pass integrations with The Wallet Crew. This guide covers API authentication, pass updates, webhooks, scans, reporting, and the paths that support each workflow.

Open API reference

Real-world examples
  • Create a loyalty pass after signup or checkout.

  • Update pass fields after a CRM, ticketing, or POS event.

  • Forward wallet lifecycle events to a backend, CRM, or analytics stack.

Start here

Most developer projects follow the same path.

1

Get credentials

Generate an API key from the admin console, in Settings → Security → API Keys. Send it in the X-API-KEY header on every request.

2

Open the API reference

Use the API reference to inspect endpoints, request bodies, response schemas, permissions, and live examples.

3

Make a first request

Start with a pass that already exists rather than a creation flow. This is the fastest way to validate tenant access, authentication, and update behavior without mixing creation logic into the first test.

The most common first call is a forced pass update. It tells the platform to re-fetch data from configured providers, rebuild the pass, and push the updated version to the device:

PATCH /api/{tenantId}/passes?id={passId}
X-API-KEY: {api_key}
Content-Type: application/json

{
  "additionalData": { "loyaltyTier": "gold" },
  "options": { "updateMetadata": true }
}

A pass can also be targeted by an external identifier instead of passId, for example id.shopify.customerId={customerId}. See Key concepts for the difference between the two. A 200 response means the update ran synchronously; 202 means it was queued.

If no pass exists yet, start with Enrolment flows or Connector-triggered pass creation instead, then come back to this call once a pass is issued.

Continue with Getting started with the API for the full walkthrough.

4

Expand the integration

Once the first management call works, move to creation flows, updates, webhooks, scans, and reporting.

Authentication

Some tenant-scoped APIs support other authentication models or extra scopes, for example the OAuth2 flow used by certain administrative operations. When that applies, the endpoint guide or the API reference is the source of truth.

For a first integration, start with APIs documented around X-API-KEY. This is the usual path for pass management, webhooks, scans, and the interactive API reference.

API reference

Use the API reference when the exact payload shape, response schema, or endpoint behavior matters.

Developer guides

These guides cover the main integration patterns.

Common next steps

After the first request succeeds, the next step usually depends on the integration goal.

FAQ

How do I create an API key?

Generate an API key from the admin console, then send it in X-API-KEY for the main platform APIs described in Start here.

How should an API key be stored?

Keep API keys in server-side secret storage. Do not expose them in browser code, mobile applications, logs, or source control.

Where is the API reference?

Use API reference for the main API entry point.

What is the best first API call?

A forced update on an existing pass is usually the best first call because it validates tenant access, authentication, and the update path without depending on a creation flow.