A shopper earns 200 points on an order. Their balance is about to expire in a week. They just crossed the threshold where a win-back campaign would make sense. Until now, none of that reached the merchant's marketing tools — loyalty wallet activity stayed locked inside Shopflo, so a merchant running a points programme couldn't send a single message about it.

That's changed. Wallet credit and debit events now go out on the same pipe that already carries your Meta and GA4 events — enriched with the details that make a campaign possible: days to expiry, whether it's the shopper's first time earning, and whether their balance just crossed a threshold.

Every time a shopper earns or spends loyalty points on your store, Shopflo fires one of two events — shopflo_wallet_credit or shopflo_wallet_debit — downstream to your connected marketing or CRM tool.

LimeChat is wired up directly — turn it on and events start flowing. For WebEngage, MoEngage, and CleverTap, events go out through a generic webhook to an endpoint you provide.

→ Apps & Integrations → Rewards & Loyalty → LimeChat (or Webhook) → Configure → Activate

If you're wiring up a webhook, these are the two events to listen for. event_type is what tells them apart.

shopflo_wallet_credit fires when a shopper earns points. Its transaction_type is CREDIT.

Useful fields: shopper.is_first_time_earner is true on a shopper's very first earn, which is your onboarding trigger. wallet.balance_crossed_threshold is true when their balance just crossed a threshold, which is your win-back trigger. expiry.expires_at and expiry.days_to_expiry are what you schedule reminders off. transaction.amount and wallet.balance_after are what you put in the message copy.

shopflo_wallet_debit fires when a shopper spends points. Its transaction_type is DEBIT.

Useful fields: transaction.amount is what they just redeemed. wallet.balance_after is what you compare against a floor to trigger a top-up journey. expiry here describes the shopper's remaining balance, not the points they just spent.

Dedupe on event_id. It's the same value as transaction_id, and delivery is at-least-once, so the same event can arrive more than once.

Earn confirmation — fires within minutes of the credit. "You just earned ₹825. Balance: ₹1,200. Expires 12 Mar."

Expiry reminder cascade — T-7, T-3, and T-1 day nudges before points lapse, so breakage doesn't happen silently.

First-time earner onboarding — the shopper's balance was zero before this order, so walk them through how redeeming actually works.

High-balance win-back — balance crosses a threshold and a re-engagement journey fires. "You have ₹1,000+ sitting in rewards."

Redemption confirmation and top-up — on the burn side, confirm what a shopper spent, and nudge them to earn more if their balance drops below a floor.

Next-expiry surface — tell a shopper when their remaining points expire, not just the ones they just used.

Discount suppression — keep shoppers who already hold a large wallet balance out of discount campaigns, protecting margin.

Segments and attribution — build cohorts like has_active_wallet_balance, expires_in_30d, or dormant_earner, and measure how a wallet nudge turns into an order.

Points are one of the strongest reasons a shopper comes back — but only if someone reminds them the points exist. A wallet balance a shopper never hears about is a discount that never gets redeemed and a message that never gets sent. This is the first release where a merchant can actually act on wallet activity, instead of it sitting silently in the background.

Two events, two destinations, for now. Only shopflo_wallet_credit and shopflo_wallet_debit, and only LimeChat and the generic webhook are supported — more destinations are expected to follow.

Shopflo doesn't schedule your reminders. The event carries expiry context (days to expiry, both as a readable date and a timestamp), but the T-7/T-3/T-1 cascade is built and scheduled inside your own marketing platform — that's deliberate, since that's where you already invest in journey building.

It's forward-only. Historical wallet events aren't backfilled — you'll start seeing events from the point this is turned on for your account.

Retries, then a dead letter queue. If a delivery fails, Shopflo retries three times with exponential backoff before it lands in a DLQ, so a transient outage on your end shouldn't mean a lost event.

→ How to Configure and Integrate Google Analytics (GA4) with Shopflo? — another destination on the same event pipe

→ How to integrate Omnisend with Shopflo — sync checkout events to power email and SMS automation

→ How to setup Reward Rally with Shopflo — one of the loyalty programs whose wallet activity this covers

Need help? Reach out to us at support@shopflo.com and we'll be happy to assist.