Use Temporal to start and manage durable workflow executions from Sim. Connect to the server's HTTP API, supply the namespace, and add an API key if the server uses bearer authentication. Your server must expose the HTTP API at a URL Sim can reach; http://localhost:7243 is an example for a local server, not a guarantee that the API is enabled on every deployment.
Start executions: Supply the workflow type, task queue, and JSON arguments. Configure ID reuse policy, cron, timeouts, memo, or search attributes where needed. Signal With Start atomically signals an execution, creating it if necessary; it does not guarantee exactly-once application processing.
Interact with executions: Send signals, query state, or invoke an update handler and wait for its result.
Inspect executions: Read status, timing, pending activities, event history, or the close event. List and count use Temporal's visibility query language.
Manage execution lifecycle: Request cancellation, terminate immediately, or reset to a past workflow task. Schedule actions create, list, inspect, pause, unpause, trigger, or delete schedules.
Inputs use Temporal's standard json/plain payload encoding, and result payloads are decoded into JSON values. Workers must accept that encoding; custom payload codecs may need a separate adapter. A top-level JSON array is treated as the argument list; any other JSON value becomes one argument. The workflow's worker must already implement the named type and poll the selected task queue.
Starting an execution acknowledges its creation, rather than its completion. Poll its state or history before consuming a final outcome. See Temporal's workflow messaging reference for signal and update semantics.
Use a Temporal server’s HTTP API to start or signal executions, query or update workflow state, inspect execution history and workers, manage schedules, and cancel, terminate, or reset executions. Supply an API key when the server requires bearer authentication.
API key sent as a Bearer token (leave blank for servers without auth)
workflowId
string
Yes
Unique workflow ID for the new execution (e.g., order-1234)
workflowType
string
Yes
Registered workflow type name to run (e.g., OrderWorkflow)
taskQueue
string
Yes
Task queue the workflow worker polls (e.g., orders)
input
string
No
Workflow input as JSON. A top-level array is passed as the argument list (one argument per element); any other value is passed as a single argument
workflowIdReusePolicy
string
No
Policy for reusing a closed workflow ID: WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE, WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE_FAILED_ONLY, WORKFLOW_ID_REUSE_POLICY_REJECT_DUPLICATE, or WORKFLOW_ID_REUSE_POLICY_TERMINATE_IF_RUNNING
workflowIdConflictPolicy
string
No
Policy when a workflow with the same ID is already running: WORKFLOW_ID_CONFLICT_POLICY_FAIL, WORKFLOW_ID_CONFLICT_POLICY_USE_EXISTING, or WORKFLOW_ID_CONFLICT_POLICY_TERMINATE_EXISTING
API key sent as a Bearer token (leave blank for servers without auth)
workflowId
string
Yes
Workflow ID to signal, or to start and signal (e.g., order-1234)
workflowType
string
Yes
Registered workflow type name to start if the workflow is not running
taskQueue
string
Yes
Task queue the workflow worker polls (e.g., orders)
signalName
string
Yes
Name of the signal handler to invoke (e.g., approve-order)
input
string
No
Workflow start input as JSON, used only when a new execution is started. A top-level array is passed as the argument list; any other value is passed as a single argument
signalInput
string
No
Signal input as JSON. A top-level array is passed as the argument list (one argument per element); any other value is passed as a single argument
workflowIdReusePolicy
string
No
Policy for reusing a closed workflow ID: WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE, WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE_FAILED_ONLY, WORKFLOW_ID_REUSE_POLICY_REJECT_DUPLICATE, or WORKFLOW_ID_REUSE_POLICY_TERMINATE_IF_RUNNING
workflowIdConflictPolicy
string
No
Policy when a workflow with the same ID is already running (defaults to using the existing run): WORKFLOW_ID_CONFLICT_POLICY_FAIL, WORKFLOW_ID_CONFLICT_POLICY_USE_EXISTING, or WORKFLOW_ID_CONFLICT_POLICY_TERMINATE_EXISTING
Invoke an update handler on a running Temporal workflow and wait for its result. Unlike a signal, an update is validated by the workflow and returns a response.
API key sent as a Bearer token (leave blank for servers without auth)
workflowId
string
Yes
Workflow ID of the execution to reset
runId
string
No
Run ID of a specific run to reset (defaults to the latest run)
workflowTaskFinishEventId
number
Yes
Event ID of the workflow task finish event to reset to — a WORKFLOW_TASK_COMPLETED, WORKFLOW_TASK_TIMED_OUT, WORKFLOW_TASK_FAILED, or WORKFLOW_TASK_STARTED event (find it with Get Workflow History)
reason
string
No
Reason for the reset, recorded in the workflow history
API key sent as a Bearer token (leave blank for servers without auth)
scheduleId
string
Yes
Unique ID for the new schedule (e.g., nightly-report)
workflowId
string
Yes
Workflow ID for started workflows (the schedule appends the run time to keep IDs unique)
workflowType
string
Yes
Registered workflow type name the schedule starts (e.g., ReportWorkflow)
taskQueue
string
Yes
Task queue the workflow worker polls (e.g., reports)
input
string
No
Workflow input as JSON. A top-level array is passed as the argument list (one argument per element); any other value is passed as a single argument
cronExpressions
string
No
Cron expressions defining when the schedule fires, comma- or newline-separated for multiple (e.g., "0 12 * * *"). At least one of cronExpressions or intervalSeconds is required
intervalSeconds
number
No
Fixed interval between actions in seconds. At least one of cronExpressions or intervalSeconds is required
timezone
string
No
IANA time zone for cron evaluation (e.g., America/New_York; defaults to UTC)
overlapPolicy
string
No
Policy when an action would overlap a still-running one (defaults to skip): SCHEDULE_OVERLAP_POLICY_SKIP, SCHEDULE_OVERLAP_POLICY_BUFFER_ONE, SCHEDULE_OVERLAP_POLICY_BUFFER_ALL, SCHEDULE_OVERLAP_POLICY_CANCEL_OTHER, SCHEDULE_OVERLAP_POLICY_TERMINATE_OTHER, or SCHEDULE_OVERLAP_POLICY_ALLOW_ALL
notes
string
No
Human-readable notes stored on the schedule
paused
boolean
No
Create the schedule in a paused state (defaults to active)
API key sent as a Bearer token (leave blank for servers without auth)
scheduleId
string
Yes
ID of the schedule to trigger
overlapPolicy
string
No
Overlap policy for the triggered action (defaults to the schedule's policy): SCHEDULE_OVERLAP_POLICY_SKIP, SCHEDULE_OVERLAP_POLICY_BUFFER_ONE, SCHEDULE_OVERLAP_POLICY_BUFFER_ALL, SCHEDULE_OVERLAP_POLICY_CANCEL_OTHER, SCHEDULE_OVERLAP_POLICY_TERMINATE_OTHER, or SCHEDULE_OVERLAP_POLICY_ALLOW_ALL
