Two types of integrations, two very different experiences
Every Klaviyo integration falls into one of two categories: native or custom. At a glance, the difference comes down to who built the connection and how much heavy lifting is required to get it running.
Native integrations
Native integrations are built and maintained by Klaviyo. They come with pre-built connectors, established workflows, and generally don't require developer resources.
Kaviyo has 350+ native integrations. Designed to be straightforward, you can connect your techstack to Klaviyo without feeling like you need a developer to check your work. The migration guidance from the last lesson applies directly here.
Custom integrations
Custom integrations are built by the client or their development team using Klaviyo's APIs. Unlike third-party integrations (owned by integration partners and implemented like native integrations), custom integrations offer more flexibility but come with more complexity, longer timelines, and more stakeholders to manage.
There are a few ways "custom" can apply:
- Your client is building their own connection using Klaviyo's APIs
- Your client isn't on a supported platform (ex: Shopify, Magento, WooCommerce, etc.)
- Your client has specific use cases that standard integrations don't cover
- Your client uses a platform that Klaviyo doesn't currently support natively
How to scope a custom integration
“There are more moving parts, more stakeholders, higher expectations. You can't escape it in digital marketing. Set expectations early, know when to pick up the phone, and always go above and beyond.”
- Pip Savaris , Client Success Director at Klaviyo Master Elite Partner Andzen
Remember when we said to gather your requirements early?
Integration complexity is one of the biggest predictors of how your client’s (and your) onboarding experience will go, and custom integrations add that complexity. You can't scope your way out of every problem, but you can do some early preparation by following the steps below:
Read up on Klaviyo’s data model first
Before you start asking your client what they want to track, you need to understand where that data actually lives in Klaviyo and what it can do once it gets there.
This is not just technical housekeeping. It directly affects what your client can build, who they can reach, and what they can report on.
Here is how Klaviyo thinks about data:
- Profiles are people. Every person in your client's account is a profile. Profiles store identity data and properties like account type, loyalty status, or location.
- Events are actions. When someone places an order, views a product, or submits a quiz, that is an event. Events are timestamped, tied to a profile, and carry properties with them like order value, product ID, or item quantity.
- Catalogs are product libraries. If your client sells products, their catalog is what powers product recommendations and dynamic product blocks in emails.
Why does this matter to your client?
Because where data lives determines what your client can do with it. Data stored on a profile can be used for segmentation. Data that travels with an event can be used for flow filtering and dynamic content in templates. But not all data works everywhere. Klaviyo's segmentation tool and report builder each have limits on what they can access. If your client's dev team sends data to the wrong place, or without the right structure, those use cases break.
For a deeper dive, check out Klaviyo's data model documentation.
Your pre-kickoff homework:
Pull up your client's website and walk through it like a first-time visitor. Click around. Add something to the cart. Browse a product page. Create an account if you can.
Write down every action you take. Each one is a potential event your client may want to track in Klaviyo.
Walk into kickoff with a working hypothesis about what their integration needs to do. You're not looking for answers yet, but this will help you shape your questions.
Use kickoff to translate your client’s goals into Klaviyo terms
One thing to know before you start: whether you're working with your agency's dev team, a dev agency, your client's dev team, or even Klaviyo's professional services team, you'll notice a language barrier, even when you both speak the same native language. Your job is to bridge the gap between marketers and developers. Keep that in mind as you work through these questions.
What current automations do you use in your previous email platform? Account creation emails, browse abandonment, post-purchase sequences, anything. And how did you segment customers by behavior previously?
How do those automations trigger? What action does someone take on your site for that email to send?
How are you planning to use that data? This matters more than it sounds. The answer changes what needs to be captured and how it needs to be structured.
- Build segments and target customers
- Feed dynamic data into messaging templates
- Build reports
Does that data need to live on the profile for segmentation, or travel with the event for flow filtering? For example: account type (consumer vs. retailer) lives on the profile. Product category viewed lives on the event.
Are you collecting subscribers on your site outside of Klaviyo forms? If so, those profiles will need to be sent to Klaviyo via the subscribe profiles API.
After kickoff: hand off to your client's dev team.
You did your job. Now, it's time to help your Developers do theirs.
We recommend that you share a technical scoping document to capture everything you uncovered in kickoff in a format that the Developer team can actually use. Work through it together if that makes it easier. The more detail you add up front, the easier it is for your Dev team to build out this dream integration.
Send your client's dev team a recap email that covers everything discussed in kickoff. Use the template below as your starting point, and customize the event samples based on what you uncovered.
[EXAMPLE EMAIL BLOCK]
Subject: Klaviyo integration recap + next steps
Hi [dev team contact],
Great meeting today. Attached is a recap of what we discussed, along with a scoping document that outlines the events we want to track and what each one needs to do in Klaviyo.
A few things to keep in mind as you build:
- Add objects to the properties array for segmentation or flow splits
- Add objects to the profile array to update a property on the profile
- Use $value to track revenue. This should be a numeric value, not a string
- If [client] uses a product catalog, make sure the item ID in your events matches the item ID in the catalog
For full API documentation and additional guidance, head to the Klaviyo Developer Portal.
Let me know if you have any questions.
[Your name]
We have step-by-step instructions on how to run a custom integration in phase 2 of the Onboard a client to Klaviyo project plan !