Put the Klaviyo account in the brand's legal name, keep the brand's card on the billing profile, and give the agency named user seats plus scoped API keys. Agency ownership is faster to stand up and easier to invoice, and it costs the brand the two assets it cannot rebuild: a consent record with original provenance, and a sending reputation attached to a domain it controls. The extra setup work is roughly twenty minutes per account. The cost of skipping it only appears on the day the relationship ends, which is the worst possible moment to discover it.
Key takeaways
- Account in the brand's legal name, brand's card on file, agency gets named seats and per-tool API keys instead of the owner login.
- Profiles, properties and backdated events are portable. Consent provenance, live flow state, metric IDs and domain reputation are not.
- Sending from a subdomain of the brand's own root domain is the highest-value ownership decision you make, because mailbox providers judge the domain, not the account.
- Ownership does not shift legal liability. Under CAN-SPAM more than one party can be responsible for the same message.
- Run an offboarding dry run in month one. If you cannot produce a clean export and a rebuild plan in a day, the account is not portable.
- If one operator owns every brand in the portfolio, this stops being an ownership question and becomes an architecture question.
What ownership actually decides
Ownership decides three things and nothing else: who pays, who can lock the other party out, and whose name sits on the consent record. Everything people usually argue about (who logs in, who builds flows, who sees the reporting) is a permissions question, and permissions can be arranged the same way under either model.
That framing matters because both sides tend to argue the wrong point. Agencies say they need ownership to work efficiently, which is a permissions claim in disguise. Brands say they need ownership for control, which is closer, but the control that counts is narrower than they think. It is the ability to keep sending, keep proving consent, and keep the reputation they paid for if the relationship ends badly.
Klaviyo lets you move the owner seat between users, so the mechanical part of a handover is small. What a settings change does not do is re-paper anything: invoices already issued, the entity that accepted the terms, and any commercial arrangement between the agency and Klaviyo stay where they are. Assume the clicks are easy and the paperwork is the slow part.
What survives an offboarding and what does not
Assume a hostile split with thirty days of notice, then ask what you can carry into a fresh account. The honest answer is more than most brands fear and considerably less than most agencies imply.
| Asset | Portable | What you actually lose |
|---|---|---|
| Email addresses and profile properties | Yes | Nothing, if you export before access is revoked. Pull via CSV or the profiles endpoint with cursor pagination. |
| Consent status and opt-in provenance | Partly | You can import subscribed profiles, but the source, method and original timestamp travel as fields you carry yourself. Miss them and you cannot evidence consent later. |
| Order and engagement history | Partly | Events accept a custom timestamp, so history can be replayed. Predictive values and any modelled scores restart from the imported data. |
| Metric IDs | No | Klaviyo mints a new ID per metric per account. Anything referencing an ID by hand points at nothing in the destination. |
| Flows and templates | Rebuild | Logic is reproducible. Live flow state (who is sitting in which delay, who has already received step two) does not transfer, so a careless cutover re-sends. |
| Segments | Rebuild | Definitions are easy. Membership recalculates from whatever history you managed to import, so engagement windows are wrong until the new account accumulates its own data. |
| Suppression list | Yes | Nothing, if you export it. This is the one nobody remembers and the one with legal consequences. |
| Domain and IP reputation | No | Reputation follows the sending domain and IP. If those change, you start again. |
| Historical reporting | No | Year-over-year comparisons stay in the old account. Export the numbers you care about as flat files before you lose access. |
The row that catches people out is metric IDs. Because every metric is minted fresh in the destination, every flow trigger, segment condition and saved report that was wired to an ID has to be remapped by metric name. This is the same failure that breaks copied flows between accounts you already control, which I covered in why cloned Klaviyo flows break in the destination account.
Who should hold the billing profile
The brand, with its own card, paying Klaviyo directly. The billing holder is the party who can stop sending, and the party a support agent will treat as authoritative in a dispute. Every other permission arrangement is negotiable. This one is the lever.
The rebilling model (agency card on file, agency invoices the brand for the platform cost plus a margin) fails in both directions. The brand cannot see what the platform actually costs, cannot verify the profile count it is being billed on, and loses sending the moment the agency's card fails or the agency decides to apply pressure. The agency, meanwhile, is carrying float on a five-figure annual bill for a client that can leave with thirty days of notice, and is the one taking the loss if invoices go unpaid while sends continue.
If the agency wants the margin, take it on services or on a platform management fee that is visible on the invoice. Reselling a subscription at an undisclosed markup is a poor trade for the amount of trust it costs when the brand eventually sees the platform's own pricing page.
Who should hold API keys and integrations
Nobody should be sharing the owner login, which is the question actually hiding underneath this one. Klaviyo private API keys are created per account and scoped per resource, with read-only or full access set individually, as described in Klaviyo's API authentication documentation. Issue one key per tool, name it for the tool and the party holding it, and revocation becomes a single click instead of a password reset that quietly breaks eight integrations at once.
Two rules cover most of the risk. First, no shared human credentials: every person who touches the account gets a named seat, so the audit trail attributes changes to a person and offboarding one contractor does not require rotating everything. Second, anything you build in-house should authenticate through OAuth rather than a stored private key, so access is granted and revoked by the account rather than by whoever has the string in a config file.
One portfolio detail worth knowing before you design tooling around a shared credential: rate limits are enforced per account and per endpoint across burst and steady windows, per Klaviyo's rate limit documentation. Cross-account jobs need per-account queues regardless of who owns the login, which I worked through in why one API key throttles six Klaviyo brands.
Who is liable for the sends
Both parties, usually, which is why liability is a bad reason to pick either model. The FTC's CAN-SPAM guidance states plainly that more than one person may be held responsible for a single commercial message, that a company promoting its own products does not escape liability by hiring another firm to handle the email, and that opt-out requests must be honored within ten business days (FTC CAN-SPAM compliance guide). Penalties are assessed per non-compliant message, which is what makes a mishandled suppression list expensive rather than embarrassing.
The operational consequence is specific. Suppression lists and consent evidence are compliance artifacts, not marketing assets, and they have to be exported and carried across at every handover, in both directions. An agency that inherits a list without provenance is inheriting exposure, and should treat it accordingly before the first send. That decision is its own piece of work: clean, suppress or restart an inherited list.
Why the sending domain outranks the login
If the agency owns the sending domain, the brand's reputation is not portable at all, and this is the ownership mistake with the longest tail. Mailbox providers evaluate the sending domain and IP, not the platform account behind them. Google's requirements for bulk senders sit on the domain: SPF and DKIM authentication, DMARC alignment, one-click unsubscribe, and a spam complaint rate held below 0.3 percent, per Google's email sender guidelines. None of that history follows you to a new domain.
Set it up so the sending subdomain is a child of the brand's root domain (send.brandname.com, not mail.agencyname.com), with the DNS records living in DNS the brand controls. The agency needs the record values to hand over, not the registrar login. Done this way, a change of agency is a platform migration with a warm domain. Done the other way it is a migration plus a cold start, and you are back to a warm-up schedule and throttled volume during the exact period when a new agency is trying to prove itself. See how to warm a new sending domain, and for portfolios, sending domain models for multi-brand Klaviyo.
How to run a portfolio without owning the logins
Standardize instead of centralizing. The efficiency an agency loses by not owning accounts is almost entirely recoverable through convention, and four conventions do most of the work.
- A naming schema for metrics, profile properties, flows and segments that is identical in every account, so a script written once resolves by name everywhere. Detail in designing a Klaviyo schema for multi-account reporting.
- A seat convention: one named seat per person per account, at the same role level, created at kickoff and removed at offboarding from a checklist rather than from memory.
- A key convention: one scoped key per tool, named identically across accounts, stored in one secrets manager on the agency side and revocable by the brand at any time.
- A reporting pull into storage you control, so portfolio numbers do not depend on continued access to any one account. The reconciliation traps are covered in why multi-brand rollup reports never line up.
If you are a multi-brand operator who owns every brand outright, this question collapses. There is no counterparty, so the decision is purely structural and belongs in one Klaviyo account or one per brand. Ownership only becomes contentious when two balance sheets are involved.
The offboarding dry run
Run it in the first month of the engagement, not the last, because a dry run performed under notice is a negotiation and a dry run performed at kickoff is just housekeeping. Budget half a day.
- Export the full profile set with consent fields, plus the suppression list, and store both outside the platform.
- Export flow definitions and templates, or at minimum screenshot every flow's trigger, filters and timing, so logic can be rebuilt without access.
- Export the reports you use for year-over-year comparison as flat files.
- List every integration touching the account, and for each one record which key it uses and who can rotate it.
- Confirm the sending domain's DNS records sit in a zone the brand controls, and that someone on the brand side can log in and read them today.
- Write down who holds the owner seat and the billing card, and what the transfer steps would be.
The pass criterion is simple: a competent operator with those files and no platform access could rebuild a sending account in a week. If the answer is no, you have found the dependency before it becomes a hostage.
Trade-offs and what I would do
Client-owned costs the agency real friction. Access requests take a day instead of a minute, a brand-side admin can break a flow you built and blame the tooling, and you will occasionally be locked out mid-campaign by an overzealous security review. Agency-owned removes all of that and creates a single point of failure sitting on someone else's balance sheet. I still recommend client-owned in almost every case, because the friction is a daily inconvenience with a workaround and the failure is an existential problem with none.
Three exceptions I would accept. A brand that has not incorporated yet, with a written transfer trigger tied to the date it does. A pilot under ninety days doing campaign sends only, where nothing accumulates that is painful to lose. And a portfolio operator whose agency is functionally an internal team under the same ownership, where the counterparty risk does not exist.
The arrangement I would refuse outright is agency-owned with a verbal promise to transfer later. Transfers happen when the relationship is healthy and stop happening the moment it is not, which is precisely when the promise is called in. If both sides genuinely intend to transfer eventually, transfer now, while it takes twenty minutes and nobody is angry.
One last note for brands reading this: the correct time to raise ownership is during onboarding, phrased as process rather than suspicion. Ask for the account in your name, your card on file, your DNS, and named seats for the agency team. A competent agency will have a documented answer, because it has been on the receiving end of the alternative at least once.