Skip to main content
POST
Create task output

Authorizations

X-API-Key
string
header
required

API key authentication. Include your API key in the X-API-Key header as: X-API-Key YOUR_API_KEY

Example:

Authorization
string
header
required

JWT Bearer token authentication. Include your access token in the Authorization header as: Bearer YOUR_ACCESS_TOKEN

Example:

Body

application/json

Database model for node output.

flow_execution_id
string<uuid>
required
organization_id
string<uuid>
required
summary
any
required
task_name
string
required
created_at
string<date-time>
id
string<uuid>
modified_by
string
output
unknown
status
enum<string>
default:queued

Valid status values for flow execution lifecycle.

Status Transitions: queued → running → in_progress → completed → failed

Status Definitions: - queued: Execution created but workflow not yet started - running: Workflow started, initial tasks executing - in_progress: Workflow actively processing tasks - completed: All tasks finished successfully - failed: One or more tasks failed, workflow stopped - deleted: Soft deleted, hidden from list operations - stale: Previously completed but data is now outdated

Available options:
queued,
running,
in_progress,
completed,
failed,
deleted,
stale,
awaiting_input
tags
unknown
updated_at
string<date-time>

Response

Task output successfully created

API model representing a task's output data.

Task outputs store the summarized, structured results of task executions. Unlike task executions which track the full lifecycle (input, output, error), task outputs focus on the final output data formatted for display, downstream consumption, and workflow decision logic.

Key Differences from Task Execution: - Task Execution: Full execution record with input, output, error, retries - Task Output: Summarized result optimized for querying and display - One task execution typically produces one task output upon completion

Resource Hierarchy: Organization → Flow → Flow Execution → Task Output

flow_execution_id
string<uuid>
required

ID of the parent flow execution containing this task. Establishes the execution hierarchy and organization scope.

Example:

"223e4567-e89b-12d3-a456-426614174000"

id
string<uuid>
required

Unique identifier for this task output. Auto-generated UUID assigned at creation time. Used for direct resource access via GET /task-outputs/{id}.

Example:

"123e4567-e89b-12d3-a456-426614174000"

organization_id
string<uuid>
required

ID of the organization owning this task output. Inherited from parent flow execution. Used for Row-Level Security (RLS) and multi-tenant isolation.

Example:

"323e4567-e89b-12d3-a456-426614174000"

status
string
required

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)
Examples:

"queued"

"running"

"completed"

"failed"

"deleted"

"stale"

summary
any
required

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}
Examples:
task_name
string
required

Name of the task that produced this output. Case-sensitive identifier matching flow definition YAML. Used to associate output with specific workflow task.

Required string length: 1 - 200
Examples:

"extract_data"

"send_email"

"validate_document"

created_at
string<date-time> | null

ISO 8601 timestamp when task output was created (UTC). Represents when the output was recorded in the system. NULL for legacy records created before timestamp tracking.

Example:

"2025-01-24T10:30:00Z"

flow_version
integer | null

Version number of the flow definition used for execution. Matches flow_version from parent flow execution. NULL for outputs created before version tracking. Useful for tracking output changes across flow versions.

Required range: x >= 1
Example:

1

modified_by
string
default:system

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')
Examples:

"system"

"123e4567-e89b-12d3-a456-426614174000"

"integration"

output
any | null

Full output data produced by the task. May be large or complex; use summary field for UI display. Can be dict, list, or primitive types. NULL if task produces no output data. Available for downstream task consumption in workflows.

Example:
tags
any | null

Task-level tags for categorization and filtering. Typically list of strings or dict with tag metadata. NULL if no tags associated with this output.

Common patterns:

  • Simple: ['priority:high', 'reviewed']
  • Structured: {'status': 'approved', 'reviewer': 'user@example.com'}
Example:
updated_at
string<date-time> | null

ISO 8601 timestamp of last update to this output (UTC). Changes when summary, output, tags, or status are modified. NULL for records never updated since creation.

Example:

"2025-01-24T10:35:00Z"