Skip to main content
GET
Retrieve a specific task execution

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:

Path Parameters

task_execution_id
string<uuid>
required

Unique identifier of the task execution to retrieve. This is the UUID assigned when the task execution was created. Task executions are scoped to organization via RLS; attempting to access another organization's task execution returns 404.

Response

Task execution successfully retrieved

API model representing a task execution within a flow.

Task executions track individual task invocations during flow execution. Each task can execute multiple times (retries, loops), identified by task_execution_idx. Contains full execution context including inputs, outputs, errors, and lifecycle metadata.

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

flow_execution_id
string<uuid>
required

ID of the parent flow execution containing this task. Establishes the execution hierarchy and determines organization scope. All tasks in a flow execution share the same flow_execution_id.

Example:

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

id
string<uuid>
required

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

Example:

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

organization_id
string<uuid>
required

ID of the organization owning this task execution. Inherited from parent flow execution for tenant isolation. Used for Row-Level Security (RLS) filtering and authorization. All task executions are scoped to a single organization.

Example:

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

status
string
required

Current execution state of the task. Valid values: 'queued', 'running', 'completed', 'failed', 'deleted', 'stale'.

Status transitions:

  • queued → running: Task execution started
  • running → completed: Task succeeded with output
  • running → failed: Task encountered error
  • any → deleted: Task soft-deleted (hidden from list operations)
  • completed/failed → stale: Task data is outdated

Queued: Task scheduled but not started Running: Task actively executing Completed: Task finished successfully (output field set) Failed: Task encountered error (error field set) Deleted: Soft-deleted, excluded from queries (preserves audit trail) Stale: Previously completed but data is now outdated

Examples:

"queued"

"running"

"completed"

"failed"

"deleted"

"stale"

task_execution_idx
integer
required

Zero-based execution index tracking task attempts. 0 = first execution, 1 = first retry, 2 = second retry, etc. Increments for each retry or loop iteration of the same task. Combines with flow_execution_id and task_name to form unique composite key.

Required range: x >= 0
Examples:

0

1

2

task_name
string
required

Name of the task as defined in the flow definition YAML. Case-sensitive identifier matching flow configuration. Used to reference task in flow logic and dependency graphs.

Required string length: 1 - 200
Examples:

"send_email"

"process_data"

"validate_input"

created_at
string<date-time> | null

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

Example:

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

error
any | null

Error information when task execution fails. Only populated when status is 'failed'; NULL for other states. Contains error message, exception type, and stack trace for debugging.

Typical structure: { "message": "Human-readable error description", "type": "Exception class name", "traceback": "Full Python stack trace" }

Used for debugging, monitoring, and error reporting workflows.

Example:
input
any

Input parameters provided to the task executor. Schema varies by task type; can be object, array, or primitive. NULL if task accepts no input parameters. Resolved from flow definition and upstream task outputs.

Examples:

"simple string input"

modified_by
string
default:system

Identifier of the actor who last modified this task execution. Tracks manual interventions vs automated updates for auditing. 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

Output data produced by the task executor upon successful completion. Only populated when status is 'completed'; NULL for other states. Available to downstream tasks via {{task_name.output}} syntax. Structure defined by task executor implementation. Used for task chaining and flow data propagation.

Example:
updated_at
string<date-time> | null

ISO 8601 timestamp of last update to this task execution (UTC). Changes whenever status, output, or error fields are modified. Used for change tracking and optimistic locking. NULL for records never updated since creation.

Example:

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