Let the official module create and manage its subscription. Do not also copy a
custom Make webhook URL into Perkstar for the same event unless two
independent deliveries are an intentional, reviewed design.
Attached webhook lifecycle
1
Make creates the attached webhook
The module sends one create request containing Make’s unique HTTPS callback,
the selected event and filters, and active state. Perkstar returns the
subscription ID that Make stores for detach; there is no separate activation
request. A retried create uses the same deterministic callback identity to
recover the live row instead of creating another subscription.
2
Perkstar records a matching event
Perkstar durably creates a delivery before scheduling the outbound POST.
Events that do not match the event type, Card, or live/test selection are
rejected before an outbound delivery is created.
3
Make accepts a bundle
An HTTP
2xx acknowledges the delivery. Acceptance by Make proves only that
its webhook endpoint received the bundle; inspect scenario history and
incomplete executions to confirm downstream modules completed.4
Make detaches the webhook
Deleting the attached webhook invokes the app’s detach operation and deletes
that app-owned Perkstar subscription. Recreating it produces a new callback
relationship. Scenario and destination history are not erased.
409 webhook_subscription_limit_reached rather than replacing another
scenario’s subscription.
Perkstar binds subscription idempotency to the live row rather than a short
response cache. A lost create response, access-token refresh, or repeated
attach call with the same app identity can recover that row. Deleting it
releases the identity and capacity immediately.
Event identity
Perkstar sends this common envelope:id and X-Perkstar-Delivery-Id identify one logical delivery and stay stable
across automatic retries. created is the source event’s data.occurredAt
expressed as Unix seconds, not the delivery-attempt time. Different events can
arrive out of order.
Use the event ID as the scenario’s duplicate key. If a destination write is
not naturally idempotent, record processed IDs in a destination uniqueness
constraint or a Make Data Store before the write. Do not assume Make will
deduplicate two accepted deliveries automatically.
Delivery policy
- Any HTTP
2xxresponse succeeds. - A non-
2xx, network failure, or response taking longer than ten seconds schedules the next attempt. 410 Gonepermanently exhausts that delivery and pauses the Perkstar subscription.- After four failed attempts, the delivery is exhausted and retained for support diagnostics.
- Delivery is at least once. Every route and destination write must tolerate a duplicate.
- Perkstar retries only when delivery to Make fails. If Make accepted the bundle and a later scenario module failed, resume or retry the Make execution with the same source identifiers.
- Use
data.occurredAtor outercreatedfor business ordering, not arrival time or Make execution time.
Server-attested delivery verification
Perkstar signs every outbound request with HMAC-SHA256 and sendsX-Perkstar-Signature: t=<unix-seconds>,v1=<hex>. Make exposes the parsed JSON
event to a custom app rather than the exact original bytes, so the official
module does not attempt to recreate the raw-body HMAC inside Make.
Instead, Watch loyalty events sends the received event and signed delivery
headers back to Perkstar over the tenant-scoped OAuth connection before it
outputs a bundle. Perkstar verifies the app-owned subscription, organisation,
authorising user, delivery ID, signing time, stored signature proof, and exact
event envelope. A missing, stale, forged, cross-tenant, or altered delivery is
rejected and does not become a normal scenario bundle. The per-subscription
signing secret remains encrypted in Perkstar and is never stored by Make.
Treat the callback URL as a secret as an additional defence: never log it,
paste it into a ticket, expose it in a screenshot, or reuse it as a public
endpoint. The stable event ID remains the duplicate key; verification proves
origin and integrity but does not turn at-least-once delivery into exactly-once
processing.
Make acknowledges the incoming HTTP delivery before the scenario’s
authenticated verification step finishes. A temporary Perkstar verification
outage therefore appears in Make as a failed or incomplete execution rather
than causing Perkstar to resend an already accepted callback. Resume that
execution with the same event ID after service recovers. The exact stored
proof remains recoverable for up to 90 days, matching Perkstar’s terminal
webhook-delivery retention; proofs older than that are rejected. Normal
duplicate handling by Event ID is still required when an execution is resumed
or replayed.
Test an instant scenario
- Add Watch loyalty events as the first module.
- Select the intended Perkstar connection and create its attached webhook.
- Choose exactly one Event and, only when that event carries a Card ID, the intended Card.
- Keep Include Test Events off for a live scenario.
- Choose Run once, then perform the exact event in Perkstar.
- Confirm the module completed its Perkstar verification request, then inspect the event ID, event type, organisation, source time, and relevant fields inside Event Data before mapping another module.
- Stop Run once, add duplicate/error handling, save, and turn the scenario on only after the test result is understood.
webhook.test diagnostic is not an Event choice. A sample bundle is not a
promise that every optional field will be populated on later events.
Observation boundaries
- Wallet Pass Installed fires on first provider-owned installation evidence. Apple reports device registration directly. Recently issued Google passes are eligible for a periodic projector; object age, provider response, and backlog can extend the delay. Issuing a pass or opening a save link is not installation evidence.
- Card Scanned covers successful online Perkstar Scanner lookups only. An offline cache lookup, dashboard search, or POS lookup is outside the event.
- Customer Card Expired belongs to one enrolment and effective expiry. If an extension later reaches a new expiry, another event is expected.
- Customer Lifecycle Group Changed tracks movement among six Perkstar lifecycle groups, not saved-segment membership. Initial classification is a suppressed baseline.
- New Customer Referral is one loyalty customer referring another. It is not a merchant, agency, partner, or affiliate invitation.

