Feature Request: Add API endpoint to fetch all dataset items with metadata filtering support

[WanderWang]

Describe the feature or potential improvement

Description:

Currently, Langfuse provides APIs to retrieve individual dataset items, but there is no efficient way to fetch all items from a dataset with custom filtering based on metadata fields.

Use Case:

When working with large datasets containing thousands of items, I need to:

• Retrieve all dataset items programmatically via API/SDK
• Filter items based on specific metadata fields (e.g., metadata.category = "type_a")
• Process items in batches to avoid performance issues

Current Limitations:

• No batch retrieval API with metadata filtering support
• Fetching all items one-by-one is inefficient for large datasets
• Metadata filtering capabilities are limited[(1)](Otel trace metadata includes all otel attributes, making filtering difficult/impossible #5583)

Proposed Solution:

Add an API endpoint (and corresponding SDK methods) that supports:

1. Fetching all dataset items from a specific dataset
2. Filtering by metadata fields using query parameters
3. Pagination support for large result sets
4. Example: GET /api/public/datasets/{datasetId}/items?metadata.field=value&page=1&limit=100

Benefits:

• Improved performance for large-scale dataset operations
• Better support for data processing pipelines
• Consistent with existing trace/session filtering patterns[(2)](https://langfuse.com/docs/observability/features/metadata)

Additional information

This would be particularly useful for evaluation workflows where datasets contain thousands of test cases that need to be processed selectively based on metadata attributes.

[maxdeichmann]

Hi @WanderWang, thanks a lot for reaching out on this one. We are aware that the dataset item API is limited in this regard. We will look into this after the christmas break.

[WanderWang]

I still have two questions:

Why does the create_datasetmethod of the Langfuse SDK lack parameters for input_schema and expected_output_schema(even though the underlying implementation has them)?

Why is there no metadata_schema? This could be quite necessary because my filtering logic is intended to be based on metadata. Having a schema would likely be safer.

[maxdeichmann]

• input_schema + expected_output_schema: we will look into this.
• metadat across langfuse objects is a freeform object. This helps especially for instrumentation to be as flexible as possible. Hence, we do not have any schema here. Enforcing this on data ingestion could lead to unexpected event rejections for our users.