Add query parameter to exclude flows data from project response

[kevinkouketsu]

Feature Request

Add a query parameter (e.g., ?exclude_flows_data=true) to the GET /api/v1/projects/{projectId} endpoint to return only project metadata and flow names without the heavy flow node data.

This could also be extended to the GET /api/v1/projects/ (list all projects) endpoint for consistency, allowing lightweight project listings across the entire workspace.

Motivation

• Expensive to compute - Loading full flow data for every request adds unnecessary database/processing overhead
• Heavy on bandwidth - Flow node data can be very large, especially for complex workflows with many components
• Inefficient for simple use cases - When you only need to:
• Check if a project exists
• List flows within a project (names/IDs only)
• Display a project overview in a UI
• Validate a project ID before performing operations

Your Contribution

Proposed Solution

Add a query parameter to control the response payload:

With exclude_flows_data=true:

GET /api/v1/projects/{projectId}?exclude_flows_data=true

{
  "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "name": "My Project",
  "description": "Project description",
  "parent_id": null,
  "flows": [
    {
      "id": "flow-uuid-1",
      "name": "Flow 1",
      "description": "Flow description"
      // No "data" field with nodes
    },
    {
      "id": "flow-uuid-2",
      "name": "Flow 2",
      "description": "Another flow"
    }
  ]
}

Without parameter (current behavior):

Returns the full response including all flow node data.

Use Cases

1. Existence checks - Quickly verify a project exists before performing operations
2. Project listing UI - Display projects and their flows in a sidebar/menu without loading megabytes of node data
3. API integrations - External systems that only need to reference project/flow IDs
4. Health checks - Validate project accessibility without heavy payload

Alternative Parameter Names

• exclude_flows_data=true
• include_flows_data=false
• compact=true

[AntonioABLima]

Thanks again for the detailed request! I have created an internal ticket (LFP-351) to track and evaluate this feature request within our roadmap.