# Route & Workflow SDKs (/docs/sdks)



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 [#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.

```mermaid
flowchart LR
  subgraph svc["Your service"]
    C["Client<br/>one per deploy"]
    W1["workflow place-order"]
    W2["workflow refund"]
    A["serve adapter<br/>/api/ductor"]
    C --- W1
    C --- W2
    C --- A
  end
  subgraph ductor["Ductor server"]
    K["coordinator + step workers"]
    P["drives runs, persists history, retries"]
    K --- P
  end
  A -->|discover| K
  K -->|execute signed| A
```

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](/docs/sdks/workflow-primitives).

<Callout type="info" title="How this relates to the DAG model">
  A workflow you author in the dashboard is a [DAG of
  steps](/docs/concepts/dag-workflow-model) 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.
</Callout>

## The three SDKs [#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.

<Cards>
  <Card title="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.
  </Card>

  <Card title="TypeScript — @ductor/sdk">
    Install with `npm install @ductor/sdk` (v0.1.0). Supports workflow execution,
    step primitives, HMAC signing, and framework adapters.
  </Card>

  <Card title="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.
  </Card>
</Cards>

<Callout type="warn" title="Check execution support">
  Go and TypeScript support workflow execution. Python supports registration
  and discovery only. See [Languages](/docs/sdks/languages) for the complete
  support matrix.
</Callout>

## Where to go next [#where-to-go-next]

<Cards>
  <Card title="Workflow primitives" href="/docs/sdks/workflow-primitives">
    The durable step-generator API — Step, Sleep, WaitForEvent, Invoke — and how
    memoized replay makes side effects run exactly once.
  </Card>

  <Card title="Bridge protocol" href="/docs/sdks/bridge-protocol">
    The signed HTTP protocol: the five actions, the opcode wire format, HMAC
    signing, and the server-side sync/checkpoint/inline-run endpoints.
  </Card>

  <Card title="Languages" href="/docs/sdks/languages">
    Per-language support matrix and serve adapters for Go, TypeScript, and
    Python.
  </Card>

  <Card title="Extensions" href="/docs/sdks/extensions">
    The eight extension-point types — strategies, plugins, CEL functions,
    middleware, providers — and how to build and ship them.
  </Card>
</Cards>