Route & Workflow SDKs
Define durable, replayable workflows in your own codebase and host them at an HTTP bridge endpoint Ductor calls back into — in Go, TypeScript, or Python.
Most of this documentation describes workflows authored inside Ductor — through the optional web dashboard, a seed, or the API. The SDKs invert that: you write workflow bodies in your codebase, in a language you already use, and host them behind an HTTP endpoint. Ductor never runs your code; it calls back into it.
That endpoint is the bridge. It is where the durable execution engine and your business logic meet.
The mental model
One Client per app deployment. You register every workflow the deployment
owns on that Client, then serve it over HTTP with a framework adapter mounted at
a bridge path (conventionally /api/ductor). When Ductor needs to advance a run,
it POSTs to that path; your handler replays the workflow from its recorded
history, runs the next un-executed step, and streams back the resulting opcodes.
The workflow body itself is just a function. Inside it you call generator-style
step helpers (Step, Sleep, WaitForEvent, WaitForSignal, Invoke) that
yield opcodes to the bridge and memoize their results, so re-invoking the
function replays prior work instead of repeating side effects. That replay model
is the whole point — see Workflow primitives.
How this relates to the DAG model
A workflow you author in the dashboard is a DAG of
steps the engine walks directly. An SDK
workflow is a remote definition: the engine drives it through the bridge,
and the bridge step type is how a DAG invokes one. Same durable guarantees,
authored in your language instead of Ductor's.
The three SDKs
Ductor ships three first-party SDKs. They are contract-locked to one another and to the server: a shared set of round-trip contract tests asserts that the opcode envelopes, protocol types, and HMAC signatures are byte-identical across all three. A workflow written against any of them speaks the same wire protocol.
Go — github.com/ductor-io/ductor-go
Install with go get github.com/ductor-io/ductor-go. The reference
implementation: execute, all step primitives, and every serve adapter are
production-ready.
TypeScript — @ductor/sdk
Install with npm install @ductor/sdk (v0.1.0). Supports workflow execution,
step primitives, HMAC signing, and framework adapters.
Python — ductor
Install with pip install ductor (or pip install ductor[fastapi] for the
FastAPI/Starlette adapters). Supports registration, discovery, health checks,
protocol types, and HMAC signing; workflow execution is not supported.
Check execution support
Go and TypeScript support workflow execution. Python supports registration and discovery only. See Languages for the complete support matrix.
Where to go next
Workflow primitives
The durable step-generator API — Step, Sleep, WaitForEvent, Invoke — and how memoized replay makes side effects run exactly once.
Bridge protocol
The signed HTTP protocol: the five actions, the opcode wire format, HMAC signing, and the server-side sync/checkpoint/inline-run endpoints.
Languages
Per-language support matrix and serve adapters for Go, TypeScript, and Python.
Extensions
The eight extension-point types — strategies, plugins, CEL functions, middleware, providers — and how to build and ship them.
Inbox
The end-user in-app notification centre — listing, the read/seen/snooze/archive lifecycle, CTAs, WebSocket sessions, and the polling fallback.
Execution Primitives
The durable step-generator API — Step, Sleep, WaitForEvent, WaitForSignal, and Invoke — and how memoized replay makes side effects run exactly once.