Principle:FlowiseAI Flowise Agentflow Listing
| Property | Value |
|---|---|
| Page ID | FlowiseAI_Flowise_Agentflow_Listing |
| Source Repository | FlowiseAI/Flowise |
| Domain | AI Workflow Orchestration, CRUD Listing Patterns |
| Last Updated | 2026-02-12 14:00 GMT |
Overview
Technique for retrieving and displaying paginated lists of agent flow configurations filtered by flow type. Agent flows are visual AI workflows that support advanced features like conditional branching, iteration loops, and multi-agent orchestration. The listing retrieves flows filtered by type (AGENTFLOW or MULTIAGENT) and supports pagination. This differs from chatflow listing by supporting multiple flow types and the V2 canvas architecture.
Description
In FlowiseAI, flows are stored in a unified chatflows data model but are distinguished by a type field. While chatflows use a fixed type filter (CHATFLOW), agent flows require a dynamic type parameter because the same listing mechanism must support both AGENTFLOW and MULTIAGENT flow types.
The agentflow listing endpoint reuses the same /api/v1/chatflows REST endpoint as chatflows, but accepts a type query parameter to filter results. This design follows the principle of endpoint reuse with query-based discrimination, avoiding the need for separate API endpoints for each flow type.
Key characteristics of the agentflow listing pattern:
- Multi-type support: Unlike
getAllChatflowswhich hardcodestype=CHATFLOW, the agentflow variant accepts a dynamic type parameter, enabling a single function to serve both AGENTFLOW and MULTIAGENT listings. - Pagination: The listing supports server-side pagination through
pageandlimitquery parameters, returning both the data array and a total count for UI pagination controls. - Shared endpoint architecture: All flow types (CHATFLOW, AGENTFLOW, MULTIAGENT) are stored in the same database table and accessed through the same REST endpoint, with type-based filtering applied at the query level.
Usage
Use this pattern when building a listing view of agent flow configurations with type filtering. This is applicable in scenarios where:
- A UI needs to display a paginated list of agent flows or multi-agent flows.
- The listing must distinguish between different flow types using the same underlying data store.
- Server-side filtering and pagination are required for performance with large numbers of flows.
Theoretical Basis
This pattern implements a filtered CRUD list pattern. Rather than creating separate endpoints and data models for each flow type, the system uses a single unified endpoint with query parameter filtering. This approach:
- Reduces API surface area: One endpoint serves multiple listing use cases.
- Simplifies data modeling: All flow types share the same schema, reducing database complexity.
- Enables flexible filtering: The dynamic type parameter allows the UI to switch between flow types without changing the underlying API call structure.
The key distinction from the chatflow listing is the parameterization of the type filter. The chatflow API function hardcodes type=CHATFLOW:
const getAllChatflows = (params) => client.get('/chatflows?type=CHATFLOW', { params })
While the agentflow API function accepts type as a parameter:
const getAllAgentflows = (type, params) => client.get(`/chatflows?type=${type}`, { params })
This parameterization is necessary because the agentflow canvas must support both AGENTFLOW (single-agent V2 flows) and MULTIAGENT (multi-agent orchestration flows), while chatflows only ever need one type.