Klaviyo Integrations: 350+ Claimed, and a Directory That Names None of Them

Klaviyo says it has more than 350 integrations. We could not count them, and the reason is worth a page of its own, because it tells you something about the platform that a number would not.

The claim, which is everywhere

"Integrate with 350+ apps to seamlessly connect all of your data to Klaviyo" appears in exactly those words on every page of the marketing site we read ^[13]. The figure is repeated in category pages, in product pages and in comparison pages, always as "350+".

The vendor is confident enough about it to use it against a rival. On its Salesforce comparison page it writes: "Klaviyo has 350+ integrations, Salesforce Marketing Cloud just 15+" ^[18]. That is a specific competitive claim, which raises the stakes on the number being checkable.

## The directory that names nothing

The integrations directory at klaviyo.com/integrations serves 1,817,706 characters of markup, roughly three times the size of any other page on the site: and that markup yields seven characters of visible text.

The seven characters are the word "Klaviyo". That is the whole page.

The page contains two div elements, no links, no SVG, and no integration named anywhere in it. Everything is script and style; the catalogue is assembled in the browser after loading from a source the markup does not contain.

We fetched it fully rendered from the United States and tested for the obvious names a directory would carry. Not one appears. The render was complete. The substance is simply not in what the server sends.

What that means for the number

Our rubric is specific on this point: a claimed integration count is not a count. Either you number them or you record the uncertainty. We record the uncertainty. That is the rule.

That is not an accusation. There is no reason to think 350 is wrong, and the vendor has every commercial incentive to be accurate about a figure it uses in competitive comparisons. What we can say is that nobody outside Klaviyo can verify it from Klaviyo's own site, which is a different statement and the only one we are entitled to make.

It also costs the vendor on our scoring. The integrations axis carries a weight of 0.146 for this category, and Klaviyo takes 3.8 on it rather than the higher figure its verifiable depth would otherwise support.

## What is verifiable, and it is substantial

Individual integration pages exist and render. We confirmed nine named ecommerce and advertising integrations with their own pages: Shopify, BigCommerce, Magento, WooCommerce, PrestaShop, Wix, Square Online, Salesforce Commerce Cloud and Instagram. Two further AI integrations have their own pages, for ChatGPT and for Claude.

Beyond those, the vendor publishes a documented public API and an MCP server in its developer documentation ^[17]. Both are open routes rather than partnerships, which means the long tail of connections does not depend on Klaviyo building them.

For this category's job: getting the right message to the right list and turning it into replies: that set covers the platforms that matter. The commerce platforms are where the orders are, and the orders are what makes Klaviyo's segmentation work at all.

The categories the vendor names

The integrations page organises the catalogue into functional groups, and the groups tell you what the platform expects to be connected to: advertising, shipping, point of sale, loyalty and subscription ^[13].

Those five are a description of an ecommerce stack rather than a marketing stack, and the difference matters when you are evaluating fit. The vendor's own framing of what each category is for is explicit: retarget customers and find lookalikes through advertising, welcome and reward members through loyalty, send shipping and delay notifications, and "Follow up, pause marketing for frustrated customers, and track support trends" from the support category ^[13].

That last one is the most interesting, because pausing marketing for a customer who has an open support complaint is a genuinely good idea that very few stacks actually implement. It requires the support system and the marketing system to share a customer record, which is the architectural argument Klaviyo makes everywhere.

## Shopify, which is a different depth from the rest

Treating Shopify as one integration among 350 understates what it is here. The vendor says over 117k brands use Klaviyo and Shopify together ^[19], which is more than half of the 205,000+ brands it claims in total.

The integration carries a guided setup that produces a sign-up form, a welcome email and an abandoned-checkout flow without leaving Shopify Admin, and the account arrives with 60+ pre-built flows and 150+ email templates ^[19]. Review requests go out through email and SMS and the resulting reviews sync back to Google Shopping, the Shop app and Meta stores ^[12]. Customer Hub runs as a signed-in area of the Shopify store itself.

That is not an integration in the sense of a data connector. It is a second product surface living inside someone else's checkout.

If you are on Shopify, read every capability claim on this page as applying fully. If you are not, read it as applying partially, and test the specific connector you depend on before you commit.

The API, and why it matters more than the count

A documented public API changes the shape of the integration question, because it moves the long tail from does the vendor support it to "can we build it".

Klaviyo publishes API documentation openly, including an events API for writing custom behavioural data onto profiles. That is the mechanism by which a business with an unusual stack gets its own data into the segmentation engine without waiting for a partnership.

The MCP server extends the same idea to AI clients: "The Klaviyo Model Context Protocol (MCP) server seamlessly integrates with Klaviyo's APIs, enabling AI clients to interact with your Klaviyo data" ^[17]. It is an open protocol, so the connection is not limited to models Klaviyo has agreed terms with.

For an evaluation, we would weigh a documented API and a working MCP server above fifty additional directory entries. The entries solve problems somebody else has. The API solves yours.

## The directory is the third instance of one pattern

This page is not an isolated oversight, and seeing the pattern is more useful than the finding.

Three separate pages on klaviyo.com serve large amounts of markup and almost no information to a reader who does not execute their scripts. The pricing page sends 601,147 characters containing no price for any email tier ^[2]. This directory sends 1,817,706 characters naming no integration. The status page sends an application that yields zero characters of text.

In every case the information exists, and in every case the page is built to assemble it in the browser. The thing each page exists to tell you: what it costs, what it connects to, whether it is working: is absent from what the server sends.

That is a single architectural decision showing up three times rather than three separate failures. It is also, increasingly, a commercial decision, because buying research now runs through systems that read what servers send. An assistant asked how many integrations does Klaviyo have reads the same seven characters we did.

For the vendor that is a self-inflicted gap in a competitive claim. For a reader it is a navigation rule: on this site, the marketing page will not answer the question and the help centre usually will.

What a missing integration actually costs

Worth thinking through before the count matters to you, because the answer is rarely "we cannot do it".

If a system is not on the list, there are three routes and they differ in cost by an order of magnitude. The first is the public API, which handles anything where you control one side and somebody can write the integration once. The second is a middleware platform, which trades a monthly fee for not writing it. The third is manual export and import, which is free and quietly expensive, because somebody does it every week and the data is stale between times.

The question that decides which route you need is not whether the integration exists but how fresh the data has to be. A loyalty balance shown in a message needs to be current to the minute. A quarterly segment of high-value customers does not.

Most teams over-specify this and end up paying for real-time plumbing to support a monthly campaign. Decide the freshness requirement first, then price the route, and the integration count stops being the question you were asking.

How to evaluate integrations for your own stack

Three steps, and none of them involves the number.

List the four or five systems that must share data with your marketing platform. Usually that is the store, the support desk, the loyalty or subscription system, and whatever holds your product catalogue.

Find the individual page for each. If a system has its own page on klaviyo.com, the integration is real and documented. If it does not, assume it needs the API until shown otherwise.

Then test the direction of flow for the one that matters most. Many integrations read from a system without writing back, or write to a profile without triggering a flow, and the difference between those is the difference between a working programme and a dashboard.

The integrations that matter most are not the ones people count

A directory count treats every connection as equivalent, and they are not. For this category's job, four connections carry nearly all the value and the rest are convenience.

The store is first and it is not close. Klaviyo's segmentation runs on purchase history, browsing behaviour and predicted value held on the profile ^[12], and none of that exists until orders flow in. An account connected to a store is a different product from one connected to a spreadsheet.

The support desk is second, and it is the one most people skip. The vendor's own framing for that category is to "Follow up, pause marketing for frustrated customers, and track support trends" ^[13]. Suppressing marketing to someone with an open complaint is the single highest-value integration behaviour in this list, and almost nobody implements it, because in most stacks the two systems do not share a customer.

Third is whatever holds your product catalogue, because personalised recommendations are only as good as the product data behind them. Fourth is loyalty or subscription, if you run either, since balance and renewal dates are the most reliable triggers a consumer brand has.

Everything after those four improves a programme that already works. Nothing before them can be substituted by having more of them.

## What we would want the vendor to change

One thing, and it is small: serve the directory as text.

The catalogue exists, the number is almost certainly accurate, and the page that would prove it is 1.8 megabytes that say nothing. Rendering the list server-side would make a competitive claim checkable, help the buyers who are now asking an assistant rather than a search engine, and cost the vendor nothing it is trying to protect.

Until then, the honest position for a reader is this: Klaviyo's integration depth is good and demonstrably so where it matters most, its breadth claim is plausible and unverifiable, and the API is the part of the story that should carry your decision.