Events and member synchronization.

An event is one thing that happened in Reward Loyalty: a member earned points, a stamp card filled up, a voucher got used. You choose which events an endpoint receives when you add it; this page lists everything on offer, what each one carries, and how to use the member data every event carries to keep your own records current.

The event catalog

You can subscribe an endpoint to any of 32 events, organized in seven groups. The badge on each event tells you what kind of fact it reports:

A ping event also exists, sent only by the Send ping button. It is a connection test, never a subscription choice.

Points and rewards

Purchases, point changes, and reward redemptions.

Stamps

Stamps earned, corrections, and stamp card rewards.

Vouchers

Vouchers claimed, issued, redeemed, and voided.

Passes

Prepaid passes issued, used, and expired.

Members and tiers

Members joining, leaving, and changing tiers.

See Member synchronization below for how these three fit together with the rest of the catalog.

Member cards

Physical member cards you issue: created, claimed, and disabled.

These events cover cards issued from your own card studio. Cards issued by the platform operator or created by members themselves send no webhook, because no single business owns those.

Privacy

Deletion notices, so your systems can remove their copy too.

See Personal data and deletion notices for what this event obliges your systems to do.

Member synchronization

Most integrations built on these events need their own copy of who a member is. Reward Loyalty gives you two tools for that: an explicit enrollment event for the moment someone joins a card, and a member fragment carried on nearly every other event, so you never have to wait for enrollment to hear about someone new.

member.enrolled fires the first time a member is explicitly enrolled on a card or stamp card: when the member joins it themselves (scanning a QR code, or following from their wallet), when staff credit a first purchase or add a first stamp on a card the member had not joined, or when a member adds a stamp card to Google Wallet before joining. It fires at most once per member per card, for a genuinely new attachment only, never for a member who already joined.

Staff crediting a first purchase does enroll the member and does raise member.enrolled. Within that one visit, the events are created in this order: the purchase is recorded first, raising purchase.recorded and points.earned, and the enrollment check runs afterward, raising member.enrolled. That does not make member.enrolled a guaranteed second event to wait for: delivery order is not guaranteed (see below), so build your integration to upsert from whichever event arrives, not to depend on member.enrolled following or leading any other event. A few other attachments happen as a side effect of another action and never raise a separate member.enrolled at all: adding a loyalty card to Google Wallet, a WooCommerce or Shopify order, an Agent or REST API follow, or a voucher bonus. Each of those surfaces as its own event instead, for example points.earned or stamp.added. To catch every attachment, subscribe to those events as well, not member.enrolled alone.

Do not use points.earned to detect a new member. It fires on every purchase that earns points, not only the first, so it tells you a balance changed, never that someone is new.

The two membership events are not symmetric. member.unenrolled fires every time a member removes the card from their wallet, while member.enrolled fires at most once per member per card. A member who leaves and later re-adds the same card raises no second member.enrolled, so over time your system can receive two member.unenrolled deliveries against one member.enrolled. Treat member.unenrolled as the current state, never as a counter to balance.

Nearly every event carries a member fragment, not just member.enrolled. Delivery order across different event types is not guaranteed, even within one operation: the example above shows a genuine enrollment landing after the purchase that triggered it, and a member's first delivery to reach you could just as easily be points.earned, voucher.claimed, or any other event that happens to fire first. Build your sync to upsert (create-or-update) your own copy of the member record from the member fragment of whichever event arrives first, keyed on member.id, rather than waiting for member.enrolled or assuming it leads. member.enrolled stays useful for what it actually signals, an explicit loyalty or stamp card enrollment, not a universal "member created" event, and some members will never trigger one at all.

Choosing events for your program type

The event picker only offers groups and events your business can currently use. A stamp-only business never sees the Passes group, for example, because there is nothing there to subscribe to:

If you subscribe an event while your business has the matching card type, then later stop using that card type, the subscription does not silently disappear. It stays active on that endpoint, still delivering, with a quiet Not in your plan badge in the picker so you remember why it is there. It stops only when you remove it yourself. A brand new endpoint can never start with an event outside what your business currently uses, and an existing endpoint can never gain a new one it did not already have.

Broad and detailed events together

One action at the counter can commit more than one loyalty fact. The broad events, points.earned and points.spent, report every balance change of their kind; the detailed events name the specific action. Selecting both is valid and common: the broad event keeps a balance mirror simple, the detailed event drives automation. Nothing is suppressed; each subscribed event arrives as its own delivery.

Every event from one operation shares one correlation_id. Each event has its own event_id, and each delivery to each endpoint has its own id. Here is one purchase arriving as two correlated deliveries:

{
  "id": "0199b7c2-4d5e-7f60-8a1b-2c3d4e5f6a7b",
  "event_id": "7d3f2a68-9c1e-4b5a-8f2d-0e6a4c8b2d19",
  "event": "purchase.recorded",
  "schema_version": 1,
  "created_at": "2026-07-10T14:32:05+00:00",
  "occurred_at": "2026-07-10T14:32:03Z",
  "partner_id": "b4a4e2b0-8f4e-4d0a-9a3f-1c2d3e4f5a6b",
  "correlation_id": "3f8c9d0e-1a2b-4c3d-8e5f-6a7b8c9d0e1f",
  "test": false,
  "data": {
    "member": {
      "id": "ee7f0d16-b176-44c5-9dd2-ee99bbc433e4",
      "unique_identifier": "344-319-665-971"
    },
    "card_id": "5b8d32c2-2b04-4033-a2dc-f750d762de88",
    "transaction_id": "e855986e-744c-4418-a4b8-6afbf7c04323",
    "purchase_amount_minor": 1250,
    "currency": "EUR",
    "points_awarded": 50,
    "source": "staff",
    "business_time": {
      "timezone": "Europe/Amsterdam",
      "local_date": "2026-07-10"
    }
  }
}

{
  "id": "0199b7c2-4d5e-7f60-8a1b-5e6f7a8b9c0d",
  "event_id": "9a5b3c71-2d4e-4f6a-9b8c-1d0e2f3a4b5c",
  "event": "points.earned",
  "schema_version": 1,
  "created_at": "2026-07-10T14:32:05+00:00",
  "occurred_at": "2026-07-10T14:32:03Z",
  "partner_id": "b4a4e2b0-8f4e-4d0a-9a3f-1c2d3e4f5a6b",
  "correlation_id": "3f8c9d0e-1a2b-4c3d-8e5f-6a7b8c9d0e1f",
  "test": false,
  "data": {
    "member": {
      "id": "ee7f0d16-b176-44c5-9dd2-ee99bbc433e4",
      "unique_identifier": "344-319-665-971"
    },
    "card_id": "5b8d32c2-2b04-4033-a2dc-f750d762de88",
    "points": 50,
    "purchase_amount": 1250,
    "transaction_id": "e855986e-744c-4418-a4b8-6afbf7c04323",
    "ledger_event": "staff_credited_points_for_purchase",
    "source": "staff",
    "balance_after": 150,
    "purchase_amount_minor": 1250,
    "currency": "EUR"
  }
}

Both carry the same correlation_id and the same transaction_id, so a consumer that receives both knows they describe one sale.

The envelope and headers

Every delivery is a POST request whose JSON body wraps the event data in a fixed envelope:

Six headers ride along with every request:

The headers mirror body fields for convenience; the signed JSON body is the authoritative copy.

A field declared for an event is always present. When a value does not apply, or an older record never stored it, the field is JSON null; a declared field never disappears from the payload.

The member object

Every member field (and the sender and receiver fields on a transfer) carries exactly two values:

{ "id": "ee7f0d16-b176-44c5-9dd2-ee99bbc433e4", "unique_identifier": "344-319-665-971" }

id is the member's internal id and unique_identifier the stable code staff and APIs use to find them. No name, email address, or other profile detail rides in a webhook payload. Look a member up through the REST API or the Agent API when a delivery needs to show more; APIs write, webhooks notify.

Money fields

Money in a webhook is always a pair: an integer field ending in _minor and an uppercase ISO 4217 currency code. The integer counts the currency's smallest unit, so the number of decimal places depends on the currency, never on the payload:

Never assume two fraction digits and never parse a formatted string; look up the fraction digits for the delivered currency code. Point counts, stamp counts, and visit counts are plain integers. A signed change ends in _delta; a named quantity such as points_expired is never negative.

The older purchase_amount field on points.earned and points.spent also carries integer minor units and stays for backward compatibility. Prefer purchase_amount_minor with currency in new integrations.

Timestamps and business time

Every exact instant in a payload is a UTC ISO 8601 string with a trailing Z, such as expired_at, claimed_at, or the envelope's occurred_at. Store and compare those as they are.

Events driven by a calendar rule (a purchase schedule, an expiry, a validity window, a birthday gift) also carry a business_time object:

"business_time": {
  "timezone": "Europe/Amsterdam",
  "local_date": "2026-07-10"
}

timezone is the owning business's IANA time zone and local_date the calendar date of the event in that zone. This answers "which business day was that?" without you re-implementing time zone math, including across daylight saving changes. Two examples on the night Amsterdam leaves summer time (October 25, 2026):

• occurred_at: 2026-10-24T22:30:00Z is 00:30 local, so local_date is 2026-10-25 while the UTC date still reads October 24.
• occurred_at: 2026-10-25T01:30:00Z is 02:30 local, after the clocks fell back, and local_date is again 2026-10-25.

That local day is 25 hours long, and both deliveries land on it. Group reports by local_date when you want business days; order and deduplicate by occurred_at, which never repeats or jumps.

Event payloads

Every event's exact fields are listed in the Webhook event field reference, one table per event with a generated example for each group. Turn there when you need the precise shape of an event's data block; the catalog above tells you which events exist and when they fire.

Related topics

• Webhook event field reference: Every field in all 32 events, with a generated example per group
• Webhooks overview and setup: Turn on Webhooks and add your first endpoint
• Security and signature verification: What the signing secret protects, and how to check it in your own code
• Deliveries, retries, and troubleshooting: Test sends, retries, auto-pause, and duplicates
• REST API overview: Look up a member's full profile after a webhook arrives
• Agent API overview: Build your own automation against the same platform