Skip to main content

When I do a flow api query against a site I notice that the updated time differs from what I see in the flows dashboard. How can I ensure that the updated time I show matches what is shown in the flows dashboard. Am I using the wrong field or something else there?

Hi ​@obviyo, great question!

 

I was able to find an answer after doing a little digging. In short:

API times will be reported in UTC.

The times you’ll see in when viewing the flows in the account will be based on your account’s set timezone.

 

If you’d like some more info, please see this post:

 

I hope this helps.

Cheers!

-Paul


Thanks for that input but that doesn’t quite answer the problem I’m running into. The dates I’m seeing are vastly different. One example is a flow where the dashboard in the UX is showing Apr. 3rd but the API updated at that comes back from a call to getFlows endpoint is showing Feb 13th so certainly not just a timezone difference in that case.


Hi ​@obviyo,

Would you mind sending over a screenshot of what you’re seeing on the flows dashboard, and also the request and response body of your GET Flows call, with any sensitive data redacted? I’d be interested in comparing the two to see if there’s a specific reason why the dates are so different. Looking forward to your response!

-Byrne


Sure - we have a simple theory now.  For the flows dashboard, that query returns something that has the latest update to the flow as well as any actions/messages under it.  For the klaviyo-api getFlows query, it only considers the flow definition(?) itself being modified.  So for example, a flow is set up, and over time just the content of the message gets edited, that “update” isn’t considered for the klaviyo-api getFlows query.  But somehow it is considered for the flows dashboard.

The chrome network tab shows the dashboard uses an internal api, that looks like this: https://www.klaviyo.com/ajax/flows/list/?archived=false&inline_recommendations=false&order_asc=false&order_by=updated&page=1&timeframe_end=2025-2-23&timeframe_key=last_7_days&timeframe_start=2025-1-24 and results in 

and the above call returns an array, with this element being

            "id": "redacted but same",
            "name": "2G - Abandonned Checkout FLOW",
            "status": "live",
            "updated": 1744220306,

And 1744220306 => Wed Apr 09 2025 10:38:26 GMT-0700

So now graphql… here’s a screenshot of what we are getting:

and the klaviyo-api getFlows returns an array, with this element being:

  attributes:
    archived: false
    created: "2025-01-03T12:36:00.000Z"
    name: "2G - Abandonned Checkout FLOW"
    updated: "2025-01-31T20:40:22.000Z"

  id: "redacted but same"

For completeness, we also included flow-actions, and there is a flow-action that was set live Apr-9 10:38a.  So we could walk all of the flow-actions, and take the max “updated” field for all flow-actions, but including flow-actions slows down the query by 10x and brings back a ton more data than we need.  And we are hoping we shouldn’t  need to do that if the API is the correct API to retrieve information similar to the flows dashboard.

Hope this helps,

-David


Bumping ​@Byrne C here! :) 


Hey ​@obviyo,

Wanted to let you know that I’m looking into this, and I’ll be back in touch with you as soon as possible.


Hi again!

After speaking with my team about the Get Flows API call, they confirmed with me that the “updated” section of the response will show the most recent time an action in the flow (or the flow as a whole) has their status changed. Because of this, changes to the individual emails or SMS messages inside the flow won’t be reflected in the response that the API call generates, and you’ll see a discrepancy between the updated time and date in the UI, and the response from the API call.


Thanks for looking into this. That aligns with what we were suspecting. Our question then is what is the Klaviyo recommended way of showing this information so that our UI can align as closely as possible with the Klaviyo Flows UI since our mutual customers will be regularly in both UIs. Our goal is to present a unified view to our mutual customers in terms of numbers/titles/dates/etc… so that there is confidence on both sides of what we are showing the end user. We want to avoid confusion as much as possible because that then introduces doubt in any other numbers or recommendations we provide.