This is an excellent and highly technical question. The short answer is that there is no single API endpoint that directly returns a list of profiles currently waiting at a specific conditional split.
The numbers you see in the Klaviyo UI (like the 22 "Yes" and 2 "No") are calculated in real-time from Klaviyo's internal application state. This state is not directly exposed through the public API as a simple query.
However, you can achieve your goal by using a combination of a small modification to your flow and the Klaviyo APIs. The most robust method is to "tag" profiles as they pass through the split and then query for those tags.
Here are two methods, with the first being the most recommended and reliable.
Method 1: The Recommended "Tag and Segment" Approach
This method involves adding a step to your flow to create a permanent, queryable property on each profile. It's the most reliable way to know for sure which path a profile has taken.
Step 1: Modify Your Flow to "Tag" Profiles
In your flow, immediately after the "Yes" and "No" branches of your conditional split, add an Update Profile Property action.
-
On the "Yes" Path:
-
Add an "Update Profile Property" action.
-
Property Name: Create a new property, e.g., flow_status_welcome_series
-
Data Type: Text
-
Value: split_path_yes
-
On the "No" Path:
-
Add an "Update Profile Property" action.
-
Property Name: Use the same property, flow_status_welcome_series
-
Data Type: Text
-
Value: split_path_no
Now, every profile that passes through this split will be permanently marked with which path they took.
Step 2: Create Segments for Each Path (Optional but Recommended)
To make querying easier, create two segments based on these new properties.
Step 3: Use the Segments API to Get the Profiles
Now you can use the API to get exactly who you're looking for.
-
Get the Segment IDs: Use the GET /api/segments/ endpoint to list all your segments and find the IDs for the two you just created.
-
Get the Profiles: Use the GET /api/segments/{segment_id}/profiles/ endpoint.
How to get the timestamp?
This method doesn't directly give you the timestamp of when they entered the split. The profile data will have an updated timestamp, which will be very close to when the property was set, but it's not a precise event timestamp. For a more precise timestamp, see Method 2.
Method 2: The Advanced "Metric Timeline" Approach
This method is more complex and involves inferring the path by looking at the timeline of events. It doesn't require modifying the flow but requires more logic in your code.
The idea is to find an event that happens right before the split and an event that happens right after the split on each path.
Step 1: Identify Key Metrics in Your Flow
-
Metric Before Split: Identify the metric associated with the action immediately preceding your conditional split. For example, if it's an email, the metric might be Received Email. You'll need the Message ID of that specific email.
-
Metric After "Yes" Path: Identify the metric for the first action on the "Yes" path (e.g., Received Email for the next message).
-
Metric After "No" Path: Identify the metric for the first action on the "No" path.
Step 2: Use the Metrics API to Correlate Timelines
You would need to write a script that does the following:
-
Fetch Profiles for "Before" Event: Use the GET /api/metrics/{metric_id}/timeline/ endpoint with the ID for the "Metric Before Split" and your desired time frame. This gives you a list of all profiles who reached the point just before the split.
-
Iterate and Check for "After" Events: For each profile you found in step 1, make another API call to the same endpoint, but this time check for the "Metric After 'Yes' Path" and the "Metric After 'No' Path".
-
If you find the "Yes" path metric for that profile, you know they went down the "Yes" path. The timestamp of that event is when they passed the split.
-
If you find the "No" path metric, you know they went down the "No" path.
Why this method is harder:
-
Multiple API Calls: It's much less efficient and can lead to rate-limiting.
-
Complex Logic: You have to handle the data correlation and time-windowing logic yourself.
-
Less Reliable: If there are no unique, trackable events immediately following the split (e.g., only a "Time Delay"), this method is not feasible.
Summary and Recommendation
Method | APIs Used | Pros | Cons |
1. Tag and Segment | Segments API | Highly reliable, simple to query, efficient (fewer API calls). | Requires a minor, one-time modification to your flow. Timestamp is approximate. |
2. Metric Timeline | Metrics API, Profiles API | Does not require flow modification, can provide a precise timestamp. | Complex logic, requires many API calls, can be unreliable if flow structure is complex. |
I strongly recommend using Method 1. It is the standard and most robust way to solve this problem in Klaviyo. The small, upfront effort of adding a profile property will save you significant development time and create a much more reliable data source for your reporting.