How does Klaviyo receive events from a store?

Through the Klaviyo API: you track an event such as a Fulfilled Order by sending its event data, and a bulk endpoint designed for high-throughput tracking accepts multiple client events in a single call.

Klaviyo vs Mailchimp: Which Data Model Fits Your Store?

At the integration layer, Klaviyo vs Mailchimp is a choice between two data models. Klaviyo's API takes store activity as events and customers as profiles, while Mailchimp's e-commerce API keeps store data inside stores that belong to an audience. Our view: Klaviyo's documented event model fits stores whose flows depend on custom e-commerce events, and Mailchimp fits email that runs from one audience with field-based personalisation. We did not assess Mailchimp's contact events.

Klaviyo vs Mailchimp at a glance

Klaviyo records store activity as events and keeps customers as profiles, while Mailchimp keeps customers, products, carts and orders inside a store tied to one audience.

Capability	Klaviyo	Mailchimp
Store-data objects	Events and profiles.	Stores, the top-level e-commerce entity, tied to an audience.
Store activity	Events sent to the Klaviyo API, one at a time or many in one bulk call.	Customers, products, carts and orders, all inside a store.
Customer identifier	A profile's unique ID, used to update its attributes.	Contacts: subscriber_hash, the MD5 hash of the lowercase email address. E-commerce customers: a client-defined customer ID.
Flow triggers	The API lists flows triggered by a list, or by metrics your OAuth app created.	Not covered in this comparison.
Customer fields	Profile attributes, updated through the API.	Merge fields, whose merge tags are replaced with their values when a campaign is sent.
Fits best (our view)	Stores whose flows depend on custom events, using its documented event model.	Stores whose email runs from one audience and its contact fields.

Our view: start with the data you already send. If your checkout and fulfilment systems emit events, Klaviyo's event model suits them; if your data is mostly contact fields, Mailchimp's merge fields suit it. Cost matters as well, and our breakdown of Klaviyo pricing covers what drives the bill.

How does each platform take in store data?

Klaviyo takes events directly through its API, one at a time or in bulk, while Mailchimp takes store data through e-commerce resources that all sit inside a store.

In Klaviyo, an application tracks a new event, such as a 'Fulfilled Order', by sending event data to the Klaviyo API. Klaviyo's bulk client events endpoint lets you submit multiple client events to Klaviyo in a single API call. That endpoint is designed for high-throughput event tracking. An empty array indicates all events were processed successfully. To read events back, Klaviyo documents retrieving them incrementally with cursor-based pagination. When you report on them, a metric rollup filter must bound the time range. The metrics endpoint returns a maximum of 200 results per page, so an integration listing metrics should page through them.

Mailchimp's e-commerce API is organised as a hierarchy. In the Mailchimp e-commerce documentation, stores are the top-level e-commerce entity, and customers, products, carts, orders and promo rules all exist inside the scope of a store. When you create a store, the required store ID is client-defined.

How Klaviyo and Mailchimp identify customers

Each platform keys customers differently: Klaviyo updates a profile by its unique ID, and Mailchimp addresses a contact inside an audience by the MD5 hash of the lowercase email address.

In Klaviyo, you can retrieve a list of profiles from your Klaviyo account, for example to reconcile them with your own customer records. One endpoint creates a new profile or updates an existing profile, and another updates the attributes of a specific profile identified by its unique ID. Sending reputation on the Klaviyo side is covered in our engineering guide to Klaviyo deliverability.

In the Mailchimp contacts documentation, contacts are addressed by subscriber_hash, the MD5 hash of the lowercase email address, so one request retrieves one contact from one audience. In the e-commerce resources, like the store ID, the customer ID is client-defined. Consent needs care during a checkout sync. Updating a customer's opt_in_status from false to true updates the member's subscription status to subscribed. Updating it from true to false does not change the subscription status. Customers who have opted out of your audience are added as transactional members.

Flow triggers and personalisation fields

Klaviyo's API can list the flows that a list or an OAuth-created metric triggers. Mailchimp personalises a campaign through merge fields and their merge tags; this comparison does not cover Mailchimp's automation API.

In Klaviyo you can retrieve all flows that use a specific list as a trigger, which requires the 'flows:read' scope. The Flows API can retrieve the set of flows triggered by metrics created by your OAuth app. For an integration that sends custom events, in our reading, that is how you check which flows a new metric will start before you switch it on. If your automations run inside Shopify instead, our guide to advanced Shopify Flow automation covers that route.

In Mailchimp, each merge field has a corresponding merge tag, a string of text like *|FNAME|*. When you send a campaign, Mailchimp replaces merge tags with the values stored in the corresponding merge fields for each recipient. To show a field on the audience's signup form, set public to true. By default, any merge field with required set to true must be included when you add a contact. Check that a sync supplies every required field before you send it, rather than finding the gap in production.

The trade-offs that decide it

Two Mailchimp constraints shape the integration: a store's audience is fixed once set, and carts stay until you delete them.

In Mailchimp, after a store is created and tied to an audience, it cannot be connected to a different audience. A single audience can support multiple stores, so, for example, several brands could share one audience. In our reading of that rule, moving a store to another audience later means creating a new store, so settle the audience structure before you connect anything. Carts do not automatically expire and will remain on Mailchimp's systems until deleted. You can read the contents of a cart, create an order with those contents, and then delete the cart. In our reading, a cart sync therefore needs its own clean-up rather than relying on expiry.

This comparison covers the data model only. It does not assess pricing, deliverability, Mailchimp's contact events or Mailchimp's automation API; the Klaviyo pricing and deliverability posts linked above cover the Klaviyo side of the first two.

Decision framework (our view): choosing your email platform

Custom events: if your flows start from events your own systems create, such as a Fulfilled Order, Klaviyo's documented event model fits.
One audience, several stores: if your stores can share one audience and personalisation runs on contact fields, choose Mailchimp.
Audience changes ahead: if you expect to restructure audiences, decide that first, because a Mailchimp store's audience is fixed once set.

What to do next

Map the data your store already produces before you choose. Our view: when flows depend on custom e-commerce events, Klaviyo's documented event model is the safer fit; confirm Mailchimp's contact events before you rule it out. When email runs from one audience with field-based personalisation, staying on Mailchimp is simpler than migrating.

List the events your checkout and fulfilment systems emit, the contact fields you rely on, and the OAuth scopes an integration will need. That list should show which model fits without a trial migration. Then test one flow end to end on a development store: send a real order event, confirm the flow it starts, and check the consent result for an opted-out customer. If you run Shopify, our Shopify Klaviyo integration work can start from that event map.