Service API

Product applications do not embed deciders, workers, or service-role credentials. They call vyuh_workflow_service.

Product Flutter UI
  -> authenticated product API
    -> service-to-service workflow API
      -> WorkflowRuntime + workers
        -> WorkflowStorage

The product server authorizes the business record and constructs the trusted tenant/application/actor context. The workflow service authorizes workflow actions, assignment, signatures, replay, and administration.

Runtime Routes

Method	Route	Purpose
POST	/v1/workflow_runs	Start one immutable version
GET	/v1/workflow_runs/{run_id}	Read one run
GET	/v1/workflow_runs/{run_id}/history	Ordered history
GET	/v1/workflow_runs/{run_id}/events	SSE revision stream
POST	/v1/workflow_runs/{run_id}/queries	Read-only query
POST	/v1/workflow_runs/{run_id}/signals	Idempotent signal
POST	/v1/workflow_runs/{run_id}/cancel	Audited cancel
POST	/v1/workflow_runs/{run_id}/redrive	Audited redrive
GET	/v1/workflow_user_tasks/{command_id}	Form-ready task
POST	/v1/workflow_user_tasks/{command_id}/claim	Claim pooled work
POST	/v1/workflow_user_tasks/{command_id}/release	Release claim
POST	/v1/workflow_user_tasks/{command_id}/complete	Complete task
POST	/v1/workflow_commands/{command_id}/retry	Retry exhausted work

Every mutation requires an idempotency key. Claims must never be accepted directly from a Flutter client.

Operations Routes

Method	Route
GET	/v1/workflow_runs
GET	/v1/workflow_user_tasks
GET	/v1/workflow_operations/health
GET	/v1/workflow_operations/readiness
GET	/v1/workflow_operations/workers
GET	/v1/workflow_operations/dead_letters
GET	/v1/workflow_versions
POST	/v1/workflow_versions/{code}/{version}/state
POST	/v1/workflow_audit_exports
GET/PUT	/v1/workflow_retention_policy
GET	/v1/workflow_recovery_readiness

See Also

• CDX Integration
• WorkflowRuntime API