Loyalty programmes only ever see purchases, because that is the only thing the shop plugin knows about.
Meanwhile the customer subscribed to your newsletter, filled in your enquiry form, booked a consultation and came to your event. All of that is engagement you would happily reward, and none of it is visible to a plugin watching order status.
One URL
Perkie gives you a single webhook endpoint. Anything that can send a web request when something happens can use it.
Deliberately not a set of per-tool integrations. An integration for MailerLite that does not cover Mailchimp, and a Zapier connector that does not cover Gravity Forms, is a maintenance treadmill and a list of things your particular stack is not on.
One endpoint that accepts a reasonable payload works with whatever you already run, including the tool you switch to next year.
Event types
Several event types with configurable points against each, so a newsletter signup and a booking can be worth different amounts. Plus a signup event that enrols someone into the rewards programme through the webhook, for tools that are already your front door.
It finds the email
The practical problem with a generic webhook is that every tool nests the email address somewhere different.
Perkie looks in the several places these commonly appear, so MailerLite, Mailchimp, Zapier, Gravity Forms and most form plugins work without you transforming the payload first. You point the tool at the URL and it works, rather than building a middleware step to reshape JSON.
Events for people who are not customers yet
This is the detail that makes it genuinely useful rather than half-useful.
Somebody subscribes to your newsletter. They are not a customer, so there is no account to award points to. The obvious behaviour is to discard the event, and the obvious behaviour is wrong: that is precisely the person you want to convert.
Perkie queues it instead. When that email address becomes a customer, the queued points are awarded. Their first look at your rewards page shows they already have a balance, from something they did before they bought anything.
The queue has an expiry window you set, defaulting to thirty days, so it does not accumulate forever.
Retries and abuse
Webhooks get sent twice. Tools retry on timeout, and a retry should not pay out again.
Perkie deduplicates within a short window, so a retry is recognised rather than rewarded. There is also a rate limit on the endpoint, because a URL that hands out currency needs one.
Seeing what arrived
An activity log of received events, so when something has not worked you can see whether the event arrived at all. That distinction is most of the debugging: if there is no entry, the problem is at the sending end, and if there is, it is at yours.
The admin screen also has the webhook URL with a copy button, the per-event configuration, and the pending queue.
It stays out of the way
Perkie puts no interface on the page where the external action happens. Your newsletter popup stays your newsletter popup, your form stays your form, designed how you designed them.
The reward happens behind the scenes. The customer sees the points on their rewards page, not a Perkie widget bolted onto somebody else’s form.
Terms stay current
Events configured through the webhook appear in your programme terms automatically, so what you are rewarding is recorded in one place rather than living only in a settings screen. There is an optional clause for disclosing third-party integrations.