Skip to main content
Contributor I
September 22, 2026

Klaviyo API - Metrics and forms

  • September 22, 2026
  • 1 reply
  • 18 views

I’m currently using the Klaviyo API, through Airbyte, to build a customer datamart that combines Klaviyo data with several other data sources.

Our company sells cards and related products for life events such as births, weddings, communions, Christmas, and other celebrations. On our website and blog, we use Klaviyo forms to collect additional information about our customers. For example, customers can indicate one or more events they are currently interested in, or provide an upcoming event date such as an expected birth date or wedding date.

The difficulty is that customers can submit these forms multiple times.

When a customer submits a form, certain Klaviyo profile properties are populated or updated. If that customer submits the form again later, the existing profile property is overwritten. As a result, the profile itself only contains the latest value and does not provide a historical view of how the customer's interests or event dates have changed over time.

I therefore hoped to reconstruct this history using Klaviyo's event data through the API. In theory, form submission or form completion events should make it possible to see what a customer submitted at a specific point in time.

However, I have run into several limitations:

  1. The event only contains the metric ID, not the metric name.
    For example, a form submission event is identified by a Klaviyo metric ID rather than a readable metric name. This makes the raw data difficult to interpret and becomes especially inconvenient when combining data from multiple Klaviyo accounts, since the metric IDs differ between accounts. You can obtain it trough get metrics API but this is not efficient. 

  2. The values submitted through the form are not included in the event.
    The profile properties that are populated or updated as a result of the form submission are not included in the form submission event itself. This is the main limitation for my use case. Even though I know that a customer submitted a form at a certain time, I cannot determine from the event which interest, event date, or other value they actually submitted.

  3. The submitted form is only identified by its ID.
    The event contains the form ID, but not the human-readable form name. To understand which form was submitted, the form ID has to be matched separately against data from the Forms API.

Because the submitted property values are missing from the event, it appears impossible to reconstruct a true historical view of these profile properties from the Klaviyo API alone.

Ideally, a form submission event would contain both the form information and the values that were submitted at that moment. That would make it possible to build a historical customer-interest dataset instead of only having access to the latest value stored on the profile.

Has anyone found a reliable way to retrieve the actual values submitted through a Klaviyo form at the time of submission, rather than only the resulting current profile properties?
 

The above includes an example of such profile property.

1 reply

Community Manager
September 24, 2026

Hi Braco, 

Thank you for providing all of this context on your question!

You are correct- Klaviyo’s standard form-submission events cannot reliably reconstruct the values submitted at each historical submission. Form submissions write values to profile properties, and later submissions can overwrite those values; the form event itself is not an append-only snapshot of the submitted fields.

 

There are two additional limitations:

  • Profile-level form events may be recorded only once per session per form, so repeat submissions may not create a corresponding event.
  • Form data can be sent through separate klaviyo.identify and subscription requests, and the event record does not necessarily retain the full submitted payload.

 

Try this structure instead:

Use Klaviyo profile properties only for the current state, and create a separate event for every submission containing the historical values:

{
"event": "Life Event Interest Submitted",
"customer_properties": {
"$email": "customer@example.com"
},
"properties": {
"form_id": "abc123",
"form_name": "Wedding Interest Form",
"interests": ["wedding", "anniversary"],
"event_date": "2027-06-12",
"submitted_at": "2026-09-24T14:30:00Z"
},
"time": "2026-09-24T14:30:00Z"
}

You can implement this in your website or backend:

  1. Listen for the successful klaviyoForms submission event.
  2. Read the submitted email, form ID, and form fields.
  3. Send a custom event through Klaviyo’s client-event or server-side event API.
  4. Continue updating profile properties if you need the latest values for segmentation.
  5. In Airbyte, ingest the custom event stream as the immutable history table.

 

Klaviyo supports listening for form activity in JavaScript, including the submitted email and form ID. The recommended pattern for preserving historical values is to track each submission as its own custom event while retaining a separate current profile property. https://developers.klaviyo.com/en/docs/track_klaviyo_form_activity_using_javascript#form-event-types

 

For existing historical data, you can only reconstruct what remains available from profile properties, form analytics, retained browser/network logs, or an external database. Klaviyo’s API alone generally cannot recover overwritten historical field values.

 

Let me know if there is anything else our team can dive deeper into on this for you!