Logs
Inspect node output
getLogs returns one log record per node, making it easy to display status, errors, and node-level timing in a technical UI.
Execution API
Start a run, then observe it.
Once a workflow returns an execution ID, the SDK exposes helpers for checking progress, reading per-node logs, cancelling a run, and waiting until the execution reaches a terminal state.
Execution methods
The namespaced executions module exposes the full lifecycle for reading status, fetching logs, and controlling history.
| Method | Purpose | Typical use |
|---|---|---|
| listByWorkflow(workflowId, options) | List runs for a workflow | Show run history in a UI |
| get(executionId) | Fetch a single execution | Read the full run object |
| getStatus(executionId) | Get current progress | Poll live progress without reading the full run |
| getLogs(executionId) | Read per-node logs | Display node output and errors |
| cancel(executionId) | Stop a running execution | Manual cancellation from the UI |
| deleteHistory(workflowId) | Delete execution history | Cleanup or reset a workflow's run history |
| waitForCompletion(executionId, options) | Poll until terminal state | Hide retry logic from the caller |
History
Track the full lifecycle
listByWorkflow and deleteHistory give you control over execution history without leaving the SDK surface.
Wait for completion
The README shows a direct polling example. The SDK also wraps that pattern in waitForCompletion so applications can keep their code small.
const execution = await client.executeWorkflow(workflowId);
const finished = await client.waitForExecution(workflowId, execution.executionId, {
timeoutMs: 60000,
pollIntervalMs: 2000,
});
console.log(finished.status);
console.log(finished.output);Status
Poll progress separately
Use getStatus when you only need the progress object and want to avoid pulling the full execution payload every time.
Terminal states
Stop polling when complete
The SDK treats success, error, and cancelled as terminal states so polling stops automatically.
Execution polling should tolerate short delays in backend indexing. A 404 immediately after execution start is usually temporary and should be retried for a brief window.