Klaviyo Loyalty Program: Smile.io vs LoyaltyLion vs Yotpo

Choosing a loyalty tool rarely comes down to the brochure. It comes down to what actually lands in Klaviyo: which events, under which names, with which profile properties, and how often. A brand that compares Smile.io, LoyaltyLion and Yotpo Loyalty & Referrals on loyalty-interface features is judging the wrong thing. What matters to the CRM is the quality of the data flow on the ESP side, because that is where segments, flows and revenue come from.

This article takes the problem from the Klaviyo end: what the platform expects from a loyalty integration, what is actually documented for each vendor, and the method for framing your choice before you sign anything.

What Klaviyo expects from a loyalty platform

Klaviyo publishes dedicated developer documentation for integrating a loyalty platform. It is the reference document, and it is worth reading even if you are not writing a line of code: it sets the standard against which any vendor should be judged.

The official event taxonomy

Klaviyo's guide to integrating a loyalty platform lists 14 expected events, split into two families.

Eleven events on points, rewards and tiers:

• Loyalty Member Enrolled
• Points Earned
• Points Redeemed
• Points Expiring Soon
• Points Expired
• Reward Earned
• Reward Redeemed
• Reward Expiring Soon
• Tier Upgraded
• Tier Downgraded
• Tier Approaching

Three events on referrals:

• Referral Sent
• Referral Started
• Referral Completed

This list is your reading grid. Every missing event is a flow you will not be able to build. No Points Expiring Soon, no reminder before points expire, so no reactivation on that lever. No Tier Approaching, no "you need X more to reach the next tier" campaign, which is one of the few loyalty mechanics that triggers an incremental order rather than subsidizing one that was already decided.

When you are framing a vendor, ask the question in these exact terms: which of the 14 events do you push into Klaviyo, and under what name? The answer fits on one line, or it does not exist.

A deliberately asymmetric naming convention

The most interesting point in Klaviyo's documentation is a rule that looks minor and is not: profile properties are prefixed with the platform's name, events are not. The documentation is explicit: "Use Title Case property names prefixed with your platform's name" and "Event names are not prefixed with your platform name."

In practical terms in the data: an event is called Points Earned regardless of vendor, while a profile property carries its issuer's brand. That is what lets two loyalty integrations coexist on the same profile without overwriting each other's data, which matters during a migration from one tool to another, a period when both run in parallel.

Operationally, that means your flow conditions built on metrics stay portable from one vendor to another, while your segments built on profile properties will need to be rewritten. A good reason to build your automations on events first, and reserve properties for display and advanced segmentation.

Three endpoints, three scopes, no magic

Technically, a Klaviyo loyalty integration rests on just three calls, listed in the same documentation:

And three OAuth scopes: profiles:read to find an existing profile before writing (matching on email and phone), profiles:write to set properties, events:write to emit events. A vendor asking for more permissions on your account deserves a question.

If your loyalty program is homegrown or connected to a custom back office, that is exactly the path described in our guide on sending Klaviyo events from your custom stack.

The technical traps that break a loyalty integration

Three points from the developer documentation are worth knowing on the CRM side, because they explain the incidents.

Tokens rotate. Klaviyo access tokens expire after one hour and refresh tokens change with every use. The documentation warns that you must persist the latest refresh token after every refresh call, or you lose the integration on the next refresh. The typical symptom on the brand side: points keep accumulating in the loyalty tool but nothing arrives in Klaviyo anymore, with no alert at all. If your loyalty flows silently drop to zero, this is the first thing to check.

API rate limits are shared. Rate limits apply per account, not per application. Several apps installed on the same Klaviyo account draw from the same call budget. A brand stacking a loyalty tool, a reviews tool, a loyalty tool being tested and a custom ERP connector does not have four budgets, it has one. Klaviyo states that standard limits absorb typical loyalty volume without particular effort, and sets the renegotiation threshold above 10 million events a day or hundreds of thousands of enrolled members per merchant, with any increase then negotiated per endpoint and per account with support and the CSM.

Backfill loads a state, not a history. At install time, catch-up goes through the bulk profile import job, and the documentation is categorical: "This is for state, not history. Don't try to replay years of events through it." You get your members' current point balance and tier. You do not get three years of event history. Any retroactive segmentation such as "customers who redeemed a reward in the last twelve months" therefore starts from the installation date. Plan for it in your measurement plan rather than discovering it while building your first segments.

What is actually documented per vendor

Here you need to separate what Klaviyo documents officially from what is vendor marketing. Klaviyo explains the rule itself on its LoyaltyLion page: integrations built by Klaviyo, called native, have documentation in the help center, while third-party apps do not, their documentation living on their marketplace listing instead. The absence of a detailed page is therefore not a quality verdict, but it does shift the burden of proof onto you during scoping.

Smile.io and Customer Hub

Smile.io is one of two vendors documented in the Customer Hub section of Klaviyo's help center. The connection is remarkably simple: according to the official procedure, you select Smile.io from the vendor dropdown under the Loyalty extension in Customer Hub, then save. No API key to handle.

What the display reference specifies about the blocks rendered in Customer Hub:

• the VIP tier icon (for example Silver VIP)
• the loyalty points balance
• the best available reward
• a progress bar toward the next best reward
• available rewards
• the individual referral link
• the ways to earn points configured in Smile.io

Two behaviors to plan for on the experience side: a profile that is not a program member sees no loyalty data, and an unauthenticated visitor is prompted to log in to access their information. That translates directly into product scoping: if your Customer Hub is your account page, non-members land on an empty area, which is both an opportunity for member acquisition and a risk of a thin page.

Be careful not to over-read this page: it describes what Customer Hub displays, not the event taxonomy that Smile.io pushes into Klaviyo. The exact metric names created on the Smile.io side are not listed on the pages reviewed. Ask the vendor directly, with the 14-event grid in hand.

Yotpo Loyalty & Referrals

Yotpo is the second vendor documented for Customer Hub, with a structuring prerequisite. According to the Klaviyo integration page, you need an active Yotpo Loyalty & Referrals account, Customer Hub live on the site, your Yotpo API key and GUID, and above all the Yotpo-to-Klaviyo integration already active and managed from Yotpo to sync profile properties and events.

This is an architecture point worth remembering: in this setup, the data flow does not originate from Klaviyo. Klaviyo consumes what Yotpo pushes. Your measurement plan is therefore scoped on the Yotpo side, and first-line support for a missing event is on the Yotpo side too.

The Yotpo Loyalty profile properties usable in Klaviyo are named swell_point_balance, swell_vip_tier_name, swell_referral_link and swell_has_account. These are your immediate segmentation building blocks: a segment on swell_vip_tier_name directly feeds a VIP logic in Klaviyo, a segment on swell_point_balance lets you target dormant balances.

Note in passing that this lowercase, underscore-based naming does not follow the prefixed Title Case convention recommended in the developer documentation. That is not a blocker, but it illustrates that a long-standing vendor can carry naming conventions that predate the current recommendation. Always check the real names in your account rather than inferring them from a guide.

LoyaltyLion

LoyaltyLion is listed on the Klaviyo marketplace. As of September 7, 2026, it does not appear among the vendors documented in the Customer Hub section of Klaviyo's help center, which lists only Yotpo and Smile.io. As explained above, that follows from Klaviyo's documentation policy: third-party apps document their own integration on their own side.

What that means for you: the events, profile properties and any flows provided by LoyaltyLion cannot be verified on a Klaviyo page. They may well be excellent. The honest approach is to have them confirmed in writing by the vendor during scoping, using the list of 14 events as a working document, rather than deciding on an impression.

The 7-question scoping method

Here is the grid we run before choosing a loyalty tool, when the decision needs to account for the CRM and not just the loyalty program itself.

1. Which events do you push into Klaviyo, with their exact names? Compare against the list of 14. Every gap becomes an impossible flow.
2. Which profile properties do you write, with their exact names? These are your future segments. Ask for a real sample profile, not a marketing screenshot.
3. Does the data flow originate from you or from Klaviyo? The Yotpo case shows how the answer changes where you debug and where you scope your measurement plan.
4. What happens on backfill? You get a state, not a history. Set the real start date of your loyalty segmentation accordingly.
5. What is the latency between the action and the event? A Points Earned that arrives hours late makes any real-time flow built on loyalty unusable.
6. What is the impact on your API call budget? Limits are per account. Inventory everything that already writes to Klaviyo before adding a new piece.
7. Who is on the hook when the data flow breaks? Three possible contacts: the loyalty vendor, Klaviyo, your integrator. Settle that before the incident, not during it.

Pricing, plans and order-volume thresholds are deliberately left out of this grid: no vendor pricing page could be verified for this article, and we do not quote a figure we have not read at the source. Ask each vendor for their current pricing directly, stating your monthly order volume.

What you do with this data once it arrives

Connecting the tool does not produce revenue. What produces revenue is what you build with the events once they are in Klaviyo.

The four uses that pay back an loyalty integration fastest:

• The reminder before points expire. It relies on Points Expiring Soon and targets a stock of value the customer has already earned. It is the closest thing to a dormant customer reactivation with a legitimate, non-promotional reason to reach out.
• The almost-there tier. Tier Approaching feeds a message that increases average order value without an extra discount.
• Enriching existing segments. Point balance and tier become extra dimensions in your RFM segments and your VIP approach. A high tier with degraded recency is not the same customer as a low tier with recent activity.
• The loyalty layer in post-purchase. Reminding customers of points earned inside the post-purchase sequence turns a transactional email into a re-engagement loop.

These uses only work if the underlying base is healthy. A loyalty program bolted onto a poorly segmented list and fragile deliverability amplifies existing problems instead of solving them. If your foundation is not there yet, our 50-point lifecycle scorecard is the better starting point, ahead of the loyalty integration.

If you want a team that works with Klaviyo daily to scope this project, that is exactly what our Klaviyo agency does.

FAQ

Should I pick a loyalty tool documented by Klaviyo?

That alone is not a sufficient criterion. Klaviyo's help center only documents its native integrations, while third-party apps document theirs on their own side. The right approach is to ask each vendor for the exact list of events and properties they push into Klaviyo, and compare it against the 14 events in the official taxonomy.

Can you run two loyalty tools in parallel on Klaviyo?

That is what the naming convention makes possible: profile properties are prefixed with the platform's name, so two integrations do not overwrite each other's data. Watch API rate limits, though, since they apply per account and not per application: two tools share the same call budget.

Do you get loyalty history at install time?

No. Klaviyo's backfill goes through the bulk profile import job and loads members' current state, not their event history. The developer documentation explicitly advises against replaying years of events through that channel. Your segmentation on loyalty events therefore starts from the installation date.

Why do my loyalty flows stop with no visible error?

The first suspect is authentication. Klaviyo access tokens expire after one hour and refresh tokens change with every use: if the latest refresh token is not persisted, the integration breaks on the next refresh. Points then keep accumulating on the loyalty tool's side while no event ever reaches Klaviyo.

What budget should I plan for Smile.io, LoyaltyLion or Yotpo?

These vendors' pricing has not been verified at the source for this article, and we do not publish a figure we have not read ourselves. Ask each vendor for their current pricing directly, stating your monthly order volume, and factor in the setup cost on the CRM side, which is rarely included in the tool's quote.

Need help scoping a Klaviyo loyalty integration? Talk to the Deliver team.