How to build a Resonate SDK

There is a formal specification that tells you exactly what wire bytes a Resonate SDK produces. There are three reference SDKs — TypeScript, Python, and Rust — that implement it. The layer between them is what this handbook is for: how you turn the protocol into a library that feels native to your language and that someone actually wants to use.

It is written for the person building the next SDK.

Spec tells you what; the handbook teaches you how

The Distributed Async Await specification defines the protocol: the promise lifecycle, the task and message model, the invariants a correct implementation must hold. This handbook assumes the spec as ground truth and teaches the layer above it — the design decisions, the idioms, and the traps that turn a wire-correct client into an idiomatic SDK.

How the handbook is organized#

Fourteen chapters, in the order you need them. The arc runs from why an SDK exists at all to what it takes to run one in production.

Who this is for#

You are comfortable in at least one language and you want to bring durable execution to it — because your community lives there, or because the runtime model is a better fit than the reference SDKs. You do not need to have read the server source. You do need to be willing to think about determinism, idempotency, and what happens when a process dies mid-flight.

If instead you want to use Resonate — build agents, workflows, and services on an existing SDK — you want the Resonate docs, not this handbook.

Have a question while you read#

Echo is Resonate's docs assistant, and it knows these pages and the spec. If something here is unclear, ask it — it answers with citations back into the source.