Skip to main content
A loyalty program is the container that ties the individual Loyalty v2 building blocks, like card definitions (point wallets), earning rules, tier structures, and rewards, into a single, customer-facing loyalty setup. Members join a program, not an individual card definition or earning rule, which is what lets a program combine several of these components into one experience.

​
Program status

A program is created in DRAFT status by default, and can be created directly as ACTIVE if it already has the required assignments. To become or remain ACTIVE, a program must have at least one active card definition and at least one active earning rule assigned; otherwise activation is rejected. Deleting a program soft-deletes it and removes all of its card definition, earning rule, reward, and tier structure assignments.

​
Assigning components to a program

Card definitions, earning rules, tier structures, and rewards are all created independently (see their respective overview pages) and then connected to a program through dedicated assignment endpoints. Most component types use a batch endpoint that can assign and unassign multiple items in a single request; unassign operations are always processed before assign operations, and, in the default strict mode, any missing resource or missing assignment fails the whole batch. A few rules are specific to each component:
  • Card definitions: They can be assigned or unassigned one at a time or in a batch, but only while the program is in DRAFT status. Unassigning fails if the card definition is still referenced by an earning rule, reward, or tier structure assigned to the same program.
  • Earning rules: They can be assigned or unassigned at any time, but if the program is ACTIVE, the batch is validated to leave at least one active earning rule assigned.
  • Tier structures: A program can have at most one tier structure assigned, and it can’t be unassigned once the program’s `ACTIVE.
  • Rewards: Each reward being assigned must include its stock configuration, which can later be updated through a dedicated endpoint without going through the batch flow. Reward purchases can also be refunded through a program-scoped refund endpoint.

​
Reporting

Aggregated program and member reports, like spending, points earnings, tier movements, and earning-rule evaluations, live in the Reports group. Use those endpoints for dashboards and analytics rather than reconstructing metrics from activity or transaction lists.

​
Activity history

Every change to a program, like creation, updates, deletion, activation, deactivation, and assignment changes, is recorded and available through its activity history endpoint. The program activity endpoint gives you an audit trail independent of your own event logging.
Last modified on August 4, 2026