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.

Overview

The Wallet Crew API lets partners and platforms create and manage wallet passes across brand workspaces. This page introduces the core concepts, explains authentication, and shows how environments and tenants are organized.

Real-world examples
  • A commerce integration creates loyalty passes from an external identifier such as shopify.customerId.

  • A platform manages several brands, with one tenant per brand and separate API keys for each environment.

  • A project validates pass issuance in staging, then switches to live keys and the production host.

What the API covers

The API is centered on pass operations. A typical integration starts from a template, creates passes for a brand, and then updates those passes over time.

A tenant represents one brand workspace. It isolates data, configuration, templates, and API access for that brand.

Templates define the structure and rules of a pass. Passes are the individual wallet objects issued through that template.

Authentication

Every request uses an API key sent in the X-API-Key header. API keys are generated in The Wallet Crew platform.

Staging and production use separate API keys. A key created for one environment does not authenticate requests in the other.

X-API-Key: <key>

Environments

The API is available in staging and production. Staging is used for validation and integration work. Production is used for live traffic and live passes.

Use one of these base URLs:

  • Staging: https://app-qa.neostore.cloud/api/{tenantId}

  • Production: https://app.neostore.cloud/api/{tenantId}

  • Production with custom domain: https://{customDomain}/api/{tenantId}

The custom domain is optional. It supports branded production integrations without changing the API model.

Working with tenants

The tenant identifier is part of the request URL. It scopes every request to one brand workspace.

A tenant can have several API keys. This supports separate integrations, key rotation, and environment-specific credentials while keeping access isolated at the brand level.

First request

The main integration flow usually starts with pass creation. The example below creates a loyalty pass in a tenant.

The identifiers object links the request to an external identity. The additionalData object carries pass-specific values used during issuance or later updates.

Versioning and changes

The API does not expose a public version in the URL today. The goal is to avoid breaking changes in the active interface.

If versioning becomes necessary, it will be introduced in the URL. When an API deprecation is required, a six-month notice is provided before removal.

Rate limits

Rate limits are defined per operation. Default limits are documented on each operation page.

Limits can also be overridden per tenant. This makes it possible to adapt throughput to a brand or integration without changing the overall API model.

FAQ

What is a tenant?

A tenant is one brand workspace in The Wallet Crew. It isolates templates, passes, configuration, and API access for that brand.

Which environment should be used during integration?

Staging is the right starting point for development and validation. Production is reserved for live traffic and live passes, with separate API keys.

Does the API require versioned URLs?

No public version is exposed in the URL today. If versioning is introduced later, it will be added to the URL, and deprecations will be announced with six months notice.

Last updated