Connecting Klaviyo to n8n: syncing profiles, custom events, and e-commerce flows

Klaviyo has become the default email and SMS marketing platform for most Shopify and WooCommerce merchants — every flow (cart abandonment, welcome, post-purchase, winback) fires on events and segments on profile properties. The problem shows up the moment a useful signal isn't natively in Klaviyo — a resolved support ticket, a risk score computed elsewhere, a Stripe payment that fails outside the Shopify checkout. n8n fills that gap: it pushes into Klaviyo exactly the profiles and events your flows need, without these third-party platforms natively talking to each other.

Generating a private API key and setting the revision

Klaviyo distinguishes public keys (for browser-side JS tracking) from private keys (for server calls). Under Settings > API Keys, create a Private API Key with the necessary scopes — profiles:write and events:write cover the uses described here, following the least-privilege principle already detailed in our API credential security guide.

In n8n, create a Header Auth credential:

• Header name: Authorization
• Value: Klaviyo-API-Key your_private_key

A second header is required on every call: revision, with a supported revision date (for example 2025-07-15). Klaviyo versions its API by date rather than a conventional version number — omitting this header, or pinning one that's too old, either fails the call or silently changes the expected response shape.

Creating or updating a profile

To make a contact exist or enrich it in Klaviyo, the server-side endpoint to use is POST https://a.klaviyo.com/api/profile-import, not the plain profiles endpoint, which fails if the profile already exists. An HTTP Request node with:

• Method: POST
• URL: https://a.klaviyo.com/api/profile-import
• JSON body: a data object of type profile, with attributes — email (or phone_number, or external_id; at least one identifier is required), first_name, last_name, and a properties object for any custom data (loyalty status, internal segment, computed score)

This endpoint resolves the profile by email, phone, or external identifier: if it already exists, its attributes are updated; otherwise it's created. It's the natural entry point for anything coming from another system — a lead enrichment flow like the one in our guide to automatically enriching leads, or a customer status update coming from your CRM synced via HubSpot or Pipedrive.

Sending a custom event to trigger a flow

An up-to-date profile isn't enough to fire an immediate action — that's the role of events, sent to POST https://a.klaviyo.com/api/events. The JSON body expects a data object of type event, with:

• metric.data.attributes.name: the metric name (for example Support Ticket Resolved or Payment Failed), created automatically in Klaviyo on first use if it doesn't exist
• profile.data.attributes: the identifier of the contact involved (email or external_id)
• properties: contextual event data, usable afterward in the flow's dynamic content
• unique_id: a unique event identifier, generated on the n8n side (for example the source resource's ID), so Klaviyo deduplicates an accidental resend instead of firing the same flow twice

Klaviyo responds with 202 Accepted: the event is accepted for asynchronous processing, not yet guaranteed to have triggered a flow at response time.

Use case: enriching a recovery flow with a signal computed elsewhere

Our guide to AI-driven cart abandonment recovery builds the entire detection and sending logic directly inside n8n. A complementary approach, when Klaviyo is already in place for e-commerce, is to let Klaviyo own the flow (timing, email/SMS channel, dynamic content) and have n8n push only the signal that's natively missing. For example: a Code node computes, from purchase history and the current cart, a repurchase-probability score finer-grained than a simple abandonment delay; that score is sent as a property of a Cart Scored event to Klaviyo, and the Klaviyo flow branches from there (a different offer depending on the score, or total silence below a threshold to avoid over-soliciting a customer unlikely to convert).

This kind of behavioral segmentation isn't a minor detail: a study by Goic, Rojas, and Saavedra, published in the Journal of Interactive Marketing in 2021 ("The Effectiveness of Triggered Email Marketing in Addressing Browse Abandonments", see on Google Scholar), shows through a field experiment that browse-abandonment-triggered emails do increase revenue compared to sending nothing, but that the effect varies sharply with the lever used in the message — gamification and curiosity outperform a plain price discount there. In other words, the signal fed into the flow (and therefore into Klaviyo) often matters more than the sending mechanics themselves.

The same principle applies to a Stripe payment that fails outside the standard checkout flow: the guide to Stripe webhooks and payment reminders covers detection; a Payment Failed event pushed to Klaviyo then routes the reminder into an existing flow rather than building a new one outside the marketing platform.

Receiving data from Klaviyo in n8n

The reverse direction is possible via the Webhook action, available inside a Klaviyo flow: it sends a POST request to an external URL with the profile and event data that triggered the flow. An n8n Webhook Trigger on the receiving end can, for example, log that a customer reached a given step of a winback flow into a tracking table, or notify a sales team that a high-value account just received a retention offer. As with any public webhook, verifying the request's origin and handling duplicate deliveries follows the same principles detailed in our n8n webhook security guide and our webhook idempotency guide.

Respecting rate limits

The Klaviyo API enforces a per-endpoint rate limit, structured as two windows: a burst limit over one second, and a steady limit over one minute — exceeding either returns a 429 error. In practice, a bulk send of profiles or events (an initial import, a full resync) hits these limits far faster than a steady stream of one-off events. A Split In Batches node to pace the send, combined with the Retry on Fail option and increasing backoff on the HTTP Request node, absorbs most 429s without manual intervention — the general method is detailed in our guide to handling AI API rate limits, directly transferable here.

Securing the API key

A private Klaviyo key grants read and write access to the entire contact base — email, phone, purchase history where applicable. It should live exclusively in an encrypted n8n credential, never in a Set node or hard-coded into an expression. Limiting the key's scopes to what's strictly needed (profiles:write, events:write, no access to campaigns or account billing) reduces the blast radius of a potential leak.

Klaviyo isn't a Brevo replacement

Both tools send emails, but they don't cover the same use case. Klaviyo is built natively for behavioral e-commerce — segmentation on purchase history, revenue attribution per flow, deep integration with the Shopify catalog — while our guide to automating email marketing with Brevo covers a more general-purpose use of newsletters and marketing sequences, independent of an online store. Running both on the same sending domain without a clear split of use cases generally hurts overall deliverability.

Going further

Pushing signals into Klaviyo that don't exist anywhere else — a risk score, a support status, a payment event — turns generic flows into genuinely personalized ones. If that score first needs to be computed from customer behavior, the guide to AI-driven churn risk scoring details the upstream mechanics. And if your main need is sorting and auto-replying to incoming email rather than marketing sends, the Inbox AI Pack (€79) covers that complementary scope; the Complete FlowKit Bundle (€269 instead of €347 bought separately) brings all packs together for anyone automating both receiving and sending.