You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We run a scheduled quality evaluation pipeline for conversational sessions. Before downloading session details, we want to select sessions matching:
A specified time range
Required trace tags
Session Duration >= 50 seconds
Each session contains multiple traces. We only need to fetch the full conversation data for sessions that pass these filters.
Current limitation
In our self-hosted Langfuse v3.194.1 deployment, the Sessions UI supports filtering by "Session Duration", but the public GET /api/public/sessions endpoint does not expose an equivalent duration filter.
Our current workflow discovers candidate session IDs, fetches each session's traces, and then calculates and filters duration locally. This requires additional requests and data transfer for sessions that are ultimately discarded.
Filtering individual traces by latency is not equivalent. For example, a session may span 120 seconds while each individual trace lasts only a few seconds.
The UI's internal session-list API appears to support the required filtering, but relying on browser authentication and internal endpoints is difficult to maintain for unattended jobs.
Requested behavior
Please provide a supported public API that can:
Filter by aggregated Session Duration, using the same definition as the Sessions UI.
Combine duration filtering with time range, trace tags, and environment filters.
Apply these filters before pagination and return lightweight results, such as session IDs and duration.
Authenticate using project API keys.
The intended workflow is:
Filter sessions on the server
→ Retrieve matching session IDs
→ Fetch details only for matching sessions
→ Run quality evaluation
Please also document the duration unit and how time-range and tag filters apply to sessions containing multiple traces, including sessions crossing the selected time boundaries.
Expected benefit
This would reduce unnecessary per-session requests and data transfer, and make UI-based and API-based session selection more consistent.
If a newer supported API already provides this workflow, guidance on the recommended endpoint and minimum self-hosted version would also be appreciated.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Describe the feature or potential improvement
Use case
We run a scheduled quality evaluation pipeline for conversational sessions. Before downloading session details, we want to select sessions matching:
Each session contains multiple traces. We only need to fetch the full conversation data for sessions that pass these filters.
Current limitation
In our self-hosted Langfuse v3.194.1 deployment, the Sessions UI supports filtering by "Session Duration", but the public
GET /api/public/sessionsendpoint does not expose an equivalent duration filter.Our current workflow discovers candidate session IDs, fetches each session's traces, and then calculates and filters duration locally. This requires additional requests and data transfer for sessions that are ultimately discarded.
Filtering individual traces by
latencyis not equivalent. For example, a session may span 120 seconds while each individual trace lasts only a few seconds.The UI's internal session-list API appears to support the required filtering, but relying on browser authentication and internal endpoints is difficult to maintain for unattended jobs.
Requested behavior
Please provide a supported public API that can:
The intended workflow is:
Filter sessions on the server
→ Retrieve matching session IDs
→ Fetch details only for matching sessions
→ Run quality evaluation
Please also document the duration unit and how time-range and tag filters apply to sessions containing multiple traces, including sessions crossing the selected time boundaries.
Expected benefit
This would reduce unnecessary per-session requests and data transfer, and make UI-based and API-based session selection more consistent.
If a newer supported API already provides this workflow, guidance on the recommended endpoint and minimum self-hosted version would also be appreciated.
Additional information
No response
All reactions