What a card definition controls
Besidesname and type, a card definition groups several independent configuration sections. Any section left out on creation falls back to a permissive default:
code_config: The pattern used to generate loyalty card codes (defaults to a 10-character alphanumeric pattern).points_expiration: Whether and how points expire (defaults toNO_EXPIRATION).pending_points: Whether newly earned points are available immediately or held back for a period, until a fixed date, or until an activation event (defaults toIMMEDIATE).earning_limitsandspending_limits: Global and per-transaction caps on how many points a member can earn or spend (default toNO_LIMIT).refunds: What happens to earned or spent points when a related order is refunded (default toNONE).balance_settings: Whether the card balance is allowed to go negative (defaults to disallowed).pay_with_points: The exchange ratio formula used when members pay for orders with points.
Lifecycle
A card definition is created inDRAFT status by default. Use the activate and draft endpoints to move it between DRAFT and ACTIVE:
DRAFT>ACTIVE: Makes the card definition eligible to be assigned to a program and used for new loyalty cards.ACTIVE>DRAFT: Makes the card definition editable again. However, you can’t change the statue toDRAFTonce it has been assigned to a program.
ACTIVE and in use — for example assigned to a program that already issued cards from it — most configuration sections become locked to protect existing point balances. Only name, metadata, and pay_with_points can always be updated regardless of usage; other sections may be rejected with a resource-locked error until the card definition is no longer referenced.
How card definitions fit into a program
Card definitions are standalone resources, created and managed independently of any single program, then connected through the Programs assignment endpoints. A program needs at least one active card definition before it can itself becomeACTIVE. An active card definition can be deleted or removed from a program only when the program itself is deleted first.
Every activity performed on a card definition, like creation, updates, status transitions, and program assignments, is recorded and available through its activity history endpoint. The activities endpoint is useful for auditing configuration changes over time.
Related resources
- Loyalty v2 API: Overview for the full Loyalty v2 API map.
- Create point wallets for the point wallet concept as presented in the dashboard.
- Programs overview to see how card definitions are assigned to a program.
- Members overview to see how loyalty cards are issued to members from active card definitions.
- Integrate loyalty v2 for an end-to-end integration walkthrough.

