Skip to main content
POST
Create a task execution record

Authorizations

Authorization
string
header
required

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

Example:

Query Parameters

large_values
enum<string>
default:inline

Controls delivery of large task values stored as GCS references. 'inline' (default) resolves references server-side and returns real values, subject to a per-request size budget (HTTP 413 when exceeded; individual references whose objects no longer exist are replaced by a 'gcs_ref_error' marker). 'refs' returns stored reference envelopes ('gcs_ref') untouched, to be resolved by the client.

Available options:
inline,
refs

Body

application/json

Request model for creating or updating a task execution.

This model is used by system workers to report task execution state. Fields are intentionally simplified to reduce worker complexity. The server infers additional fields like organization_id and timestamps.

flow_execution_id
string<uuid>
required

ID of the parent flow execution containing this task. Used to determine organization_id and maintain execution hierarchy.

Example:

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

processing_status
string
required

Processing lifecycle status of the task. Valid values: 'queued', 'running', 'completed', 'failed', 'cancelled'. Server validates against ProcessingStatus enum.

Examples:

"running"

"completed"

"failed"

task_execution_idx
integer
required

Zero-based execution index for this task. Increments for each execution of the same task (retries, loops). Combines with flow_execution_id and task_name to form unique identifier.

Required range: x >= 0
Examples:

0

1

2

task_name
string
required

Name of the task as defined in the flow definition YAML. Must match a task name in the flow's task list. Case-sensitive identifier used for task lookups.

Required string length: 1 - 200
Examples:

"send_email"

"process_data"

"validate_input"

completed_at
string<date-time> | null

ISO 8601 UTC timestamp when task execution finished on the Temporal worker. Captures actual compute end time, unaffected by result posting delays.

error
any

Error information when task execution fails. Only set when status is 'failed'. Contains error message, type, and stack trace. Structure: {'message': str, 'type': str, 'traceback': str} Used for debugging and error reporting.

Example:
input
any

Input parameters provided to the task executor. Schema varies by task type. Can be dict, list, or primitive types. NULL if task has no input parameters.

Examples:

"simple string input"

output
any

Output data produced by the task executor upon completion. Only set when status is 'completed'. NULL for queued/running/failed states. Available to downstream tasks via {{task_name.output}} syntax.

Examples:
source_task_executions
any

Tracks the original producer of this task's output data. Set by pass-through tasks (HITL, Branch, Validation) to propagate provenance. Structure: {'root': {'task_name': str, 'task_execution_idx': int}, 'fields': {...}}

started_at
string<date-time> | null

ISO 8601 UTC timestamp when task execution started on the Temporal worker. Captures actual compute start time, unaffected by scheduling delays.

terminal_task_status
enum<string> | null

When set, the task-level status row is written in the same request (atomically with this execution row), so the task can never read as completed/failed before its result data exists. Set by the workflow engine on a task's final (carrier) result post only.

Available options:
completed,
failed
usage
TaskExecutionUsageRequest · object | null

When set, the task's usage (credits) is recorded in the same request and transaction as this execution row, replacing the separate usage post. Accepted from the system worker only. The response marks it with usage_recorded=true so an older API that ignores this field is detectable.

Response

Task execution created successfully

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

edited_status
enum<string>
required

Whether this task execution was manually edited.

Available options:
not_edited,
edited_not_reexecuted,
edited_reexecuted
Examples:

"not_edited"

"edited_not_reexecuted"

"edited_reexecuted"

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"

processing_status
enum<string>
required

Processing lifecycle status of the task.

Available options:
queued,
running,
completed,
failed,
deleted,
awaiting_input,
cancel_requested,
cancelled,
skipped
Examples:

"queued"

"running"

"completed"

"failed"

stale_status
enum<string>
required

Whether this task execution's data is outdated.

Available options:
consistent,
stale
Examples:

"consistent"

"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"

completed_at
string<date-time> | null

ISO 8601 UTC timestamp when task execution finished on the Temporal worker. Captures actual compute end time, distinct from updated_at (API write time). NULL for legacy records or in-progress executions.

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"

credits
integer | null

Total credits consumed by this task execution. None when no usage records exist for this task.

Example:

10

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:
source_task_executions
any | null

Tracks the original producer of this task's output data. Set by pass-through tasks (HITL, Branch, Validation) to propagate provenance.

started_at
string<date-time> | null

ISO 8601 UTC timestamp when task execution started on the Temporal worker. Captures actual compute start time, distinct from created_at (API write time). NULL for legacy records created before timing was tracked.

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"

usage_recorded
boolean | null

Set to true only on the response of POST /task-executions when the request's inline usage was recorded in the same transaction. Null everywhere else.