ConstraintsDeleting a customer removes all their loyalty cards without publishing Loyalty Card Deleted. Treat Member Deleted as the deletion of every card that customer had.An import publishes Loyalty Card Imported only for cards that did not exist yet. A card that already exists publishes Loyalty Card State Changed, and only if the import changes its state.Loyalty Card State Changed is published only when the state actually changes. Besides a card update, it is published when creating a card replaces the customer’s active cards, when creating a card reactivates an inactive one, and when a customer is deactivated. Activating a customer does not reactivate their cards.The EventId of these events contains a random part, so a redelivered event carries a new EventId. Don’t use it alone for idempotent processing.
Published when a customer’s loyalty card changes. A loyalty card is the card a customer identifies with at the till — not a challenge card, which is covered by Card Events. Every payload carries CustomerId, MemberId and LoyaltyCardId; CustomerId equals MemberId.
Field reference
Field definitions match the loyalty card models used by the Members endpoints. See Members in the API Reference.
The mobile app equivalents (POST /mobile-app/v1/loyalty-cards and PUT /mobile-app/v1/loyalty-cards/{cardId}) and the admin portal’s card actions emit the same events. POST /v1/loyalty-cards/import/data-import behaves like /import. POST /v1/loyalty-cards/{memberId}/deactivate and PUT /v1/members/{memberId}/deactivate emit Loyalty Card State Changed for every card they deactivate.
Schemas
Last modified on October 7, 2026