Here is the job. A brand comes to us with four flows live: a welcome series written two years ago, an abandoned cart with one email in it, a post-purchase thank you, and a win-back that has been paused since March. Email is doing 14 percent of revenue. It should be doing 30.
The fix is not complicated on paper. Rebuild the welcome series with a proper segment split. Extend the cart flow to three emails with an SMS branch. Add browse abandonment, replenishment, a second-purchase nudge, a VIP track, and a sunset flow. Twelve flows, sixty or so emails, every one of them needing copy, a template, timing, filters, and exclusions.
Doing that in the Klaviyo interface takes about three weeks of real working time. Not because any single step is hard, but because there are roughly four hundred of them and each one is a click, a dropdown, and a save. That is where the Klaviyo API earns its place in the stack.
What three weeks of manual flow building actually costs
The obvious cost is time. The real cost is drift. When a human builds sixty emails across twelve flows over three weeks, the flows built in week one do not match the flows built in week three. Exclusion logic gets applied to some and forgotten on others. Someone sets a two day delay in one branch and forty-eight hours in another. Utm parameters go on half the links.
Nobody notices, because nothing breaks visibly. The flows send. Revenue goes up, so the build gets marked as a success. Then six months later someone audits the account and finds that a chunk of the list is receiving three flows at once and the sunset flow was never connected to anything. That is where the 10 to 30 percent leak in a poorly integrated flow stack comes from. It is not bad strategy. It is inconsistency at volume.
A flow stack built by hand is a document. A flow stack built from a definition is a system. The difference shows up the third time you need to change something across every flow at once.
The workflow we actually run
The approach that works is not generating flows from nothing. Klaviyo themselves recommend the pattern, and it is the right one: build a reference flow in the interface, pull its definition through the API, then modify that definition in code and create adjusted copies. You are reshaping a known-good structure, not inventing one.
In practice, for a brand rebuild, that runs in five stages.
Step 1
Pull the account as it stands
Every existing flow, metric, list, segment, and template comes down through the API into a single local file. Before anything is written, we can see the whole account in one place, including the flows that are live but sending to nobody.
Step 2
Build one reference flow by hand
One welcome series, built properly in the interface, with the segment split, the delays, the exclusions, and the SMS branch all correct. This becomes the template every other flow is shaped from. It takes an afternoon and it is the highest leverage afternoon of the project.
Step 3
Write the flow stack as a definition
Twelve flows described in one file: trigger, filters, delays, branches, exclusions, and the copy for each email. Because it is a file, it can be reviewed end to end in ten minutes. That review catches the overlap problems that would otherwise surface six months later in an audit.
Step 4
Deploy against the API, throttled
The script creates each flow from the reference definition, attaches templates by ID, sets filters, and leaves everything in draft. Create Flow is limited to 1 request per second burst, 15 per minute steady, and 100 per day, so the queue backs off rather than hammering the endpoint.
Step 5
Review in the interface, then switch on
Everything lands as a draft. A human opens the account, walks the twelve flows, checks the previews, and turns them live. The API builds. It does not publish. That line matters more than any other rule in the process.
Three weeks becomes about a day of build time plus an afternoon of review. More importantly, the twelfth flow is built to exactly the same standard as the first, because it came out of the same definition.
Where the Klaviyo API is genuinely bad
Template design is the honest weakness. Anything visually complex still gets built in the drag and drop editor and referenced by ID, because templates pushed through the API do not round-trip cleanly back into the editor. Edit one in code and the marketing person who opens it next week may find a layout they cannot cleanly modify. We keep design in the interface and logic in code, and we do not fight that boundary.
The reporting endpoints also lag the dashboard, often by a few hours. If you are trying to check same-day flow performance programmatically, the numbers will not match what the interface shows, and you will waste an afternoon assuming your script is broken when it is not.
And the rate limits are real. The 100 per day ceiling on Create Flow means a large multi-brand deployment needs to be spread over days or split across accounts. Anyone telling you they can rebuild a hundred flows in an afternoon has not read the documentation.
What this looks like in practice
The change is not that email suddenly makes more money because a script wrote it. Copy quality and offer strategy still decide that. The change is that the flow stack you designed is the flow stack that ships, in full, this month rather than next quarter.
Flow revenue should sit at 50 to 60 percent of total email revenue. Brands running a deep flow stack average 30 to 40 percent of total store revenue from email, against 15 to 20 percent for brands treating email as a broadcast channel. Most brands sitting at the low end are not there because their flows are bad. They are there because two thirds of the flows they need were never built.
Removing the build cost removes the excuse. That is the whole argument for doing this in code.
Inside the system
How we build this for brands
The Klaviyo layer does not run on its own. It sits downstream of a VOC engine that mines customer reviews and support messages into the language the emails actually use, so the welcome series is written from what buyers say rather than what the brand wishes they said. The same source material feeds the ad creative, which is why the email and the Meta ad a customer sees in the same week finally sound like one brand.
Upstream of it, a reporting agent watches the flow stack weekly against live Shopify and ad data, and flags leakage: flows overlapping on the same segment, a replenishment window drifting out of line with actual reorder timing, a sunset flow quietly catching people it should not. Part of this runs live for portfolio brands today; the full system is what we deploy when we take a brand on.
Klaviyo Audit
Find out which flows you are missing and what they are worth
I will go through your Klaviyo account flow by flow, show you where the overlaps and gaps are, and size the revenue sitting in the flows you have not built yet. You get the map and the numbers behind it.
Book Your Klaviyo AuditFrequently asked questions
Can you create Klaviyo flows through the API?
Yes, but with limits. The Create Flow endpoint is rate limited to 1 request per second in burst, 15 per minute steady, and 100 per day. The practical approach Klaviyo itself recommends is to build a reference flow in the UI, pull its definition through the API, then modify that definition programmatically and create adjusted copies. You are reshaping a known-good structure rather than generating flow logic from nothing.
What are Klaviyo's API rate limits?
Klaviyo rate limits per account using a fixed-window algorithm with a one second burst window and a one minute steady window. Limits vary by endpoint. Create Flow sits at 1 per second burst, 15 per minute steady, and 100 per day. Exceeding either window returns an HTTP 429, so any production script needs exponential backoff and a queue rather than a tight loop.
How much revenue should Klaviyo flows generate for a DTC brand?
Flow revenue should represent 50 to 60 percent of total email revenue. Brands running email as a retention system with a deep flow stack average 30 to 40 percent of total store revenue from email. Brands using email mainly as a broadcast channel average 15 to 20 percent. The gap between those two numbers is almost entirely flow coverage.
Is it worth automating Klaviyo flow builds for a single brand?
Usually not. The payback comes from repetition. If you build a flow stack once a year, the interface is faster. If you rebuild flows across multiple brands, run frequent segment splits, or version your flows the way you version code, the API pays for itself within two or three deployments. In our experience the break-even sits around the third full rebuild.
What does the Klaviyo API not do well?
Email template design is the weak point. Templates built or edited through the API do not round-trip cleanly with the drag and drop editor, so complex layouts still get built in the interface and referenced by ID. Reporting endpoints also lag the dashboard by a few hours, which makes same-day performance checks unreliable. Both are workable if you design around them.
How many flows should a DTC brand have live?
Top-performing DTC brands run 12 to 16 active flows. The non-negotiable set is welcome, cart abandonment, checkout abandonment, browse abandonment, post-purchase, replenishment or second-purchase, win-back, and sunset. Most brands sitting under 15 percent email revenue share are missing at least half of that list rather than underperforming on the flows they do have.
About the author
Caner Veli built Liquiproof to global distribution across 3,000+ retailers, then exited. He now runs Purposeful Profits using a combination of operator strategy and AI-powered systems he has built and uses daily, having 10x'd monthly revenue in his own business in the last 90 days.