This article describes the known limitations of the Klaviyo integration. These limitations are inherent to the current design of the integration and to the capabilities of the Klaviyo REST API, and they apply to all subscribers. Each is framed as a design choice rather than a defect, and reflects the integration as built at the time this documentation was written.

This integration was built for Klaviyo, the email and SMS marketing platform, using the Klaviyo REST API.

Not built for: This integration connects only to Klaviyo through the Klaviyo REST API described above. It is not built for any other Klaviyo product surface, any third-party platform that resells or wraps Klaviyo, or any other marketing platform. If Klaviyo introduces a separate product line or a materially different API version in the future, this integration will not automatically support it until it is updated and re-tested.

Klaviyo does not send change notifications (webhooks) to the integration when a profile is added or changed. To keep iPaaS.com current, the integration checks Klaviyo on a schedule for profiles updated since the last successful check and transfers each changed profile into iPaaS.com. A profile can also be brought in on demand from the iPaaS.com Manual Sync page by entering the Klaviyo Profile ID.

What this means for you: Changes made to a profile in Klaviyo are not reflected in iPaaS.com the instant they happen. They arrive on the integration's next scheduled poll, or immediately if you run a Manual Sync for that profile. If you need a specific profile updated right away, use Manual Sync rather than waiting for the next poll. This is the correct shape for Klaviyo, because Klaviyo does not offer change notifications for the integration to subscribe to. This reflects the Klaviyo platform's design at the time this documentation was written.

Note: This applies to the inbound (Klaviyo to iPaaS.com) direction. Outbound changes (iPaaS.com to Klaviyo) are driven by the iPaaS.com outbound triggers you enable, not by a poll.

When an iPaaS.com Transaction is sent to Klaviyo, the integration records a Placed Order event, and one Ordered Product event per order line. Klaviyo records events by creation only and does not change an event after it is recorded. Because of this, there is no update path for an order event: re-sending a transaction records a new event rather than altering one already in Klaviyo.

What this means for you: If an order changes after it was first sent (for example, a corrected total or an added line), the correction appears in Klaviyo as an additional event rather than a modification of the original. Each order event carries an idempotency key (mapped from the iPaaS.com Transaction or Transaction Line identifier) so that re-sending the same unchanged order does not create a duplicate. When you genuinely need a correction reflected, send the updated transaction and treat the resulting event as the current record of that order in Klaviyo. This mirrors how Klaviyo itself treats events, and reflects the Klaviyo platform's design at the time this documentation was written.

Note: This applies to the outbound order-event collections (Placed Order and Ordered Product). It does not affect inbound profile transfers.

The integration does not perform collision handling that merges two records into one. Instead, it matches an incoming record to an existing one so that a duplicate is not created:

What this means for you: The integration relies on a clean email address (and, as a fallback, a valid phone number) to recognize the same person across both systems. Profiles that have neither a usable email nor a phone number cannot be reliably matched and may be treated as new records. To get dependable matching, make sure your outbound Customer records carry an email address wherever possible, and a phone number that can be normalized to E.164 format as a backup. There is no automatic merge of two records that were created separately; matching happens at transfer time using these identifiers. This reflects the integration's design at the time this documentation was written.

Note: A phone number that cannot be normalized to E.164 format is omitted rather than sent, so it cannot be used as a fallback identifier in that case.

The integration does not offer a bulk initialization (one-time mass load) of all existing records when a subscription is first set up. Records flow through the normal transfer paths: inbound profiles arrive on the polling schedule or by Manual Sync, and outbound profiles and order events are dispatched by the iPaaS.com outbound triggers you enable (or by Manual Sync of an individual record).

What this means for you: When you first connect the integration, expect records to populate over time as they are polled or transferred, rather than all at once through a single initialization run. To bring a specific record across immediately during setup or testing, use Manual Sync with that record's ID. If a large one-time backfill is important to your rollout, submit a feature request through your iPaaS.com partner channel describing your volume and timing so that input can inform future enhancement releases. This reflects the integration's design at the time this documentation was written.

Klaviyo stores at most one address per profile, held inside the profile's own location details rather than as a separate list of addresses. The integration faithfully reflects this: on the inbound side, the profile's single address is transferred to one iPaaS.com Customer Address, and on the outbound side, the address sent to Klaviyo is read from the iPaaS.com Customer's primary billing address.

What this means for you: You cannot maintain multiple addresses (for example, separate billing and shipping addresses) on a single Klaviyo profile through this integration, because Klaviyo itself holds only one address per profile. Inbound, you will see one Customer Address per profile. Outbound, choose which iPaaS.com address feeds Klaviyo by mapping the address you want; the template mappings select the address flagged as the primary billing address. An inbound address transfers only when the profile's street address, city, and country are all present, so partially completed addresses in Klaviyo do not reach iPaaS.com. This reflects the Klaviyo platform's design at the time this documentation was written.

Note: Because the address travels as part of the profile, the inbound address collections run as a child of the parent Profile transfer rather than on their own.

When the integration updates an existing Klaviyo profile from an iPaaS.com Customer, it sends a partial update: only the fields the collection maps are written, and Klaviyo fields that the collection does not map are left as they are. The integration does not perform a full-replace write that would clear unmapped fields.

What this means for you: Editing a value in Klaviyo that the integration does not map (for example, a Klaviyo-only property) is safe; a later outbound update from iPaaS.com will not wipe it out. For the fields the integration does map, iPaaS.com is the source of truth and those values are overwritten on each outbound update. If you want a particular value to be controlled by Klaviyo rather than iPaaS.com, remove or remap that field in the outbound collection so the integration stops sending it. On the inbound side, the Update Klaviyo Profile TO iPaaS.com collection is delivered to preserve existing iPaaS.com values, so a routine inbound update does not overwrite identity fields unless you remap a field to a Klaviyo source. This reflects the integration's design at the time this documentation was written.

Note: This partial-update behavior applies to profiles. Order events follow the separate append-only model described in limitation 2.

Several template mappings and one configuration default ship with example or placeholder values that each subscriber should review and replace to match their own data before going live. Review each entry below and confirm the value is correct for your environment.

This article covers 6 known limitations of the Klaviyo integration, along with a platform scope statement and a pre-go-live placeholder checklist. For the field-by-field detail behind each collection, see the Klaviyo mapping collection descriptions in the Help Center.