Hi @danielmartinhq, hope you’re doing well! For this type of integration, and from what I’ve seen for other subscription models in Klaviyo, I’d recommend a combination of events and profile properties.
Use custom events for the actions themselves, such as sign-up, subscription started, renewal, and cancellation. Events preserve the timeline and can include details like plan, price, billing interval, platform, and cancellation reason. Keep the customer’s current state in profile properties, such as subscription status, current plan, and next renewal date. Klaviyo’s data model explains this distinction, and the Events API can be used to send those activity events directly.
Sending directly through the API is generally a good option if your app or backend is the source of truth. A middleware or CDP (like users managing subscriptions through Skio, for example) can also work well if it already handles identity matching, retries, transformations, and monitoring. The most important thing is to use one clearly defined source for each event and profile update rather than sending the same data through multiple paths.
For duplicate events, send a stable, unique ID for every real event. For example, use the individual renewal or invoice ID for renewals, not only the subscription ID, and keep the profile identifier consistent. It’s also worth deciding which system wins if events arrive late or out of order, especially for cancellations and renewals.
I hope this information is useful, and I’m curious to hear from other community members that may have approached this similarly/differently!
Temi@Klaviyo
