List all task outputs
List all task outputs across all flow executions in your organization.
Retrieve all task output records for your organization. Returns complete output data including summary, full output, tags, and status for each task that has produced output. Results are ordered by creation time (most recent first).
Important: No Pagination
This endpoint currently returns ALL task outputs in the organization without pagination.
For organizations with many flow executions, this may return large result sets. Pagination
is planned for a future release. Consider using GET /flow-executions/{id} to filter by
specific flow execution.
What Are Task Outputs
Task outputs represent the summarized, structured results of completed tasks:
- summary: Structured data optimized for UI display and querying
- output: Full output data for downstream task consumption
- tags: Categorization metadata for filtering and organization
- status: Task execution state when output was created
Filtering and Querying
Currently no query parameters are supported. To filter by flow execution, use
GET /flow-executions/{id} which includes task outputs in response.
Planned enhancements:
- Filter by flow_execution_id
- Filter by task_name
- Filter by status
- Pagination (limit, starting_after)
- Date range filtering
Performance Considerations
- Query returns all outputs (potentially thousands of records)
- Results ordered by created_at desc (newest first)
- Database query scoped to organization via RLS policies
- Consider using
GET /flow-executions/{id}for filtered results
Common Use Cases
- Export all task outputs for audit or analysis
- Debug output issues across multiple executions
- Build organization-wide analytics dashboards
- Bulk data extraction for external systems
Related Endpoints
GET /task-outputs/{id}- Get single task output by IDGET /flow-executions/{id}- Get flow execution with filtered task outputsGET /task-executions- Get full task execution details
Header Parameters
Response
Response Attributes
ID of the parent flow execution containing this task. Establishes the execution hierarchy and organization scope.
Unique identifier for this task output. Auto-generated UUID assigned at creation time. Used for direct resource access via GET /task-outputs/{id}.
Identifier of the actor who last modified this task output. Tracks who made the last change for auditing purposes. Defaults to 'system' for worker-initiated changes.
Values:
- 'system': System-automated changes (workers, background jobs)
- User ID: UUID string of the user who made the change (e.g., '123e4567-e89b-12d3-a456-426614174000')
- Integration type: For service accounts/integrations (e.g., 'integration', 'service-account')
ID of the organization owning this task output. Inherited from parent flow execution. Used for Row-Level Security (RLS) and multi-tenant isolation.
Execution status when output was created. Valid values: 'queued', 'running', 'completed', 'failed', 'deleted', 'stale'. Typically 'completed' for successful task outputs.
Status meanings:
- queued: Task scheduled but not started
- running: Task actively executing
- completed: Task finished successfully
- failed: Task encountered error (may have partial output)
- deleted: Soft-deleted, excluded from queries (preserves audit trail)
- stale: Output data is outdated (needs refresh)
Structured summary of task output for UI display and querying. Typically a dictionary with standardized keys for rendering.
Common patterns:
- Document processing: {'pages': 10, 'word_count': 5000}
- API calls: {'status_code': 200, 'response_time_ms': 450}
- Data validation: {'valid_rows': 950, 'invalid_rows': 50}
Name of the task that produced this output. Case-sensitive identifier matching flow definition YAML. Used to associate output with specific workflow task.
Response Attributes
Standard error detail structure.
This model matches the error format returned by the centralized exception handlers in app/api/errors/handlers.py.
Show child attributes
Response Attributes
Standard error detail structure.
This model matches the error format returned by the centralized exception handlers in app/api/errors/handlers.py.