Loyalty Register glossary
Webhook
An automatic message one system sends to another over HTTP when a specific event happens, carrying data about that event.
A webhook is an automatic message that one system sends to another over the web as soon as a specific event happens. The message, usually a short JSON payload sent by HTTP POST, describes the event: a member enrolled, points were earned, a reward was redeemed, a tier changed. The receiving system has a web address, called the webhook URL or endpoint, ready to accept these messages and act on them.
Updated · By Loyalty Register Editorial TeamRelated terms
What is the difference between a webhook and an API?
An API call is a request: your system asks and the other system answers. A webhook reverses the direction: the source system sends data when something changes, without being asked. That is why webhooks are sometimes called reverse APIs. They are not an alternative to APIs, and most integrations use both: a webhook to learn that something happened, an API call to fetch details or correct a record.
The usual comparison is with polling, where the receiving system asks at intervals, “has anything changed?”, which wastes requests and leaves a delay between the event and the reaction. A webhook avoids both.
How do loyalty programs use webhooks?
Typical uses include telling an email or messaging tool that a member reached a new tier, so a welcome message goes out the same day; telling the app to refresh a balance after points post; alerting a CRM or customer data platform when a member redeems; and notifying a fraud tool about unusual activity, such as many redemptions in a short time. The loyalty platform may also receive webhooks, for example from an ecommerce platform when an order ships or is returned. For how this affects points timing, see real-time or batch points posting.
What can go wrong?
Delivery can fail, and senders retry. Stripe’s documentation, a well-known public example, says delivery is retried for up to three days in live mode and that an endpoint may receive the same event more than once. If a receiver credits points on each copy, a member gets double points. Receivers therefore need idempotency: processing the same event twice must have the same effect as processing it once, usually by logging each event ID.
Messages can also arrive out of order, so a return might reach you before the purchase it reverses. Stripe warns against relying on order, and also against using event timestamps to work it out, because separate events can share one. Use a sequence number if the platform provides one. Otherwise, fetch the current state through the API before making a tier or balance decision.
How do you keep a webhook secure?
The endpoint is a public address, so anyone could try to send it a fake message. A fake “points earned” event has real value, so each message should be signed and the receiver should verify the signature before acting. Use HTTPS, and respond quickly with a success code, doing the heavier work afterward, so that slow processing does not trigger needless retries.
What should you check with a vendor?
Ask which events can trigger webhooks and what the payload contains. Ask how failed deliveries are retried, for how long, and whether you can see and replay failed messages. Confirm messages are signed. Make sure webhooks complement, rather than replace, a way to reconcile in bulk, so a missed message is found in the next daily check instead of by a member.