v1
latestOpenAPI 3.1.02026-08-06284092.1 KBCreate a workflow
Create a new workflow owned by the caller's active org (begins at v1).
Request body
Human-readable workflow name.
Optional long-form description of the workflow's purpose.
Tag values (system or org-custom) for filtering/grouping.
Allow completing the job with uncaptured steps.
Allow capturing steps in any order.
Strict (False) fails the job on any failing step; threshold (True) uses fail_threshold_percent.
Required. Maximum percentage (0-100) of evaluable steps that may fail before the job is FAILED when allow_step_failure is True. Has no effect when allow_step_failure is False, but is still required -- send 0 for strict workflows. Required (rather than defaulted) so a client enabling allow_step_failure cannot silently inherit a strict 0 threshold by omitting it.
Allow the operator to append ad-hoc steps during a run.
Example request
{
"name": "Site walk-through",
"steps": [
{
"name": "Overview shot",
"agent_id": "object-detection-v1"
}
]
}Response
Successful Response
Stable family id, unchanged across edits.
Current human-readable workflow name.
Optional long-form description of the workflow's purpose.
Tag values (system or org-custom) for filtering/grouping.
True when this is a system workflow visible to every org.
Provenance of a system workflow: 'registry' for a built-in seeded into the environment, 'user' for one promoted from an org's workflow. Null for non-system workflows.
True when this system workflow is Tiliter-authored. Tiliter-created entries sort ahead of community-promoted ones in the picker. Always false for non-system workflows.
True when the workflow has been soft-deleted.
Lifecycle state of a workflow row.
Transitions: draft -> active -> deleted. Non-draft rows skip to active on creation.
When True, the job can be completed with steps left uncaptured. When False, every step must be captured first.
When True, steps may be captured in any order. When False, they must be captured in ascending sort_order.
Selects the job pass policy. When False (strict), any step that fails its pass_criteria or errors makes the job's result FAILED. When True (threshold), failures are tolerated until the percentage of evaluable steps that failed exceeds fail_threshold_percent. Either way the job's lifecycle status is unaffected -- only a technical error makes a job COMPLETED_WITH_ERRORS.
Maximum percentage (0-100) of evaluable steps that may fail before the job is FAILED when allow_step_failure is True. Ignored when allow_step_failure is False.
When True, the operator may append ad-hoc steps during a run.
Owning user id. Null for system workflows.
Owning organization id. Null for personal workflows.
Set on an edit draft (a 'draft' row that stages changes to a live workflow): the id of the live workflow these edits will publish to. Null on active workflows and on brand-new-workflow drafts.
On an active workflow, the id of the caller's own in-progress edit draft for it, if one exists (so the client can offer 'resume editing' and show an 'unpublished changes' indicator). Null when the caller has no edit draft for this workflow.
Number of steps in the workflow.
Number of non-completed jobs currently running against this workflow.
Number of distinct users who have access to this workflow via group membership or direct ownership. Zero for system workflows.
When the workflow was first created.
When the workflow was last modified.
Example response
{
"steps": [
{
"name": "Overview shot",
"workflow_note": "Stand back and capture the whole subject in frame.",
"agent_id": "object-detection-v1"
}
]
}