Running Klaviyo across many client accounts without an access mess

Ask most retention agencies how many people currently have access to their clients' Klaviyo accounts, and the honest answer is usually "we're not entirely sure." Private API keys get shared in a password manager, a former employee's access never gets revoked, and nobody remembers which key belongs to which integration. None of this is unique to Klaviyo — it's what happens to access control at any agency running dozens of client accounts without a deliberate system.

The access sprawl problem

The failure mode is always the same shape: access accumulates and rarely gets cleaned up. A private key created for a one-off export two years ago is still active. A contractor who left the team six months ago can still technically pull data, because revoking access was never anyone's explicit job. None of this shows up as a problem until a client asks who has access to their account, and the honest answer takes an afternoon of investigation to produce.

Private API keys vs OAuth

A private API key is a long-lived credential tied to the Klaviyo account itself — whoever holds it has whatever access the key was scoped with, indefinitely, until someone remembers to revoke it. OAuth is different: access is granted per integration through a login flow the client controls, tied to a specific app with specific scopes, and the client can see and revoke it from their own Klaviyo settings at any time without needing the agency's cooperation. For a third-party tool an agency connects to a client's account, OAuth puts the access decision where it belongs — with the account owner (Klaviyo's authentication documentation covers both methods).

Least privilege in practice

Klaviyo's OAuth scopes are granular — accounts:read, flows:read, metrics:read, campaigns:write, and dozens more, each requesting only what it names. A reporting tool that only needs to read flow performance has no legitimate reason to request campaigns:write, profiles:write, or any other write scope. If a third-party tool asks for write access to show you a number, that's worth questioning before connecting it — a reporting integration's blast radius should be limited to reading, full stop.

Onboarding checklist

Five things worth confirming the moment an agency takes over or connects a new client account: what access method is in use (private key or OAuth), which conversion metric is set, a quick inventory of active flows, a baseline period to compare future results against, and who on the client side owns the Klaviyo account itself in case access needs re-confirming later.

Offboarding checklist

Just as important, and far more often skipped: when a client relationship ends, revoke the integration's access immediately rather than leaving it dormant, and confirm what happens to any published material — case studies or proof pages already sent to that client's own prospects should keep working even after the underlying account access is gone, since their content was already fixed at the point they were published.

What we do

Inteleve requests accounts:read and flows:read, and metrics:read only where the reporting genuinely needs it — never a write scope, on any account, for any reason. Tokens are encrypted at rest, never logged, never shown in the UI. If an account disconnects, its data is purged after 30 days; anything already published as a proof stays live with its content frozen from the moment it was published, independent of whether the underlying account is still connected.