--- title: "Build a client SDK" description: "Bundle marketplace nodes and flows into a client in Console → Client Builder, build it into a typed SDK in up to six languages, and call it with an API key from the environment." category: guide surfaces: [console, sdk] languages: [python, go, typescript, java, csharp, rust] related: [guides/api-keys, getting-started/invoke-via-api, concepts/nodes-packages-flows, concepts/type-system, reference/glossary] last_reviewed: 2026-06-10 --- # Build a client SDK The Client Builder turns a [client](../reference/glossary.md#client) — a named bundle of marketplace nodes and flows you assemble in the console — into a typed SDK in any of six languages: Python, Go, TypeScript, Java, C#, and Rust. The SDK uses real Protocol Buffers types and exposes one method per bundled node or flow. This guide creates a client, adds members from the marketplace, builds and downloads an SDK, and calls it. ## Prerequisites - An Axiom account you can sign in to the editor with. - Something to bundle: a published package (yours via `axiom push`, or any marketplace package) and/or a saved flow owned by your account. - An API key for runtime calls — the generated SDK authenticates every request with one (see [API keys](../guides/api-keys.md)). ## Create a client 1. In the app, go to **Console → Client Builder** (`/console/client-builder`): click **Console** in the top header — Client Builder is the first entry in the console sub-nav. It is also reachable from the command palette (⌘K, then "Client Builder"). 2. Click **New client**. 3. Enter a **Name** — the name your code will know the SDK by, such as `billing` — and click **Create client**. A client starts empty, and no language is chosen at creation: you pick the languages per build, and you can build the same client in more languages later. ## Add nodes and flows A client's **members** are the nodes and flows its SDK exposes — each member becomes one method. In the client's detail view: 1. Click **+ Add nodes & flows**. The page splits in two: the client's configuration on the left, the marketplace on the right. 2. Pick members in the marketplace panel: - **Packages tab** — click **+ Add all** on a package card to take every node in the package, or open the package and add nodes one at a time. A version dropdown on the card (and in the package detail) selects which package version to add. - **Flows tab** — click **+ Add** on a flow. Flows already in the client show **In client**. 3. Picked members collect in the tray at the bottom of the panel. Each has an **alias** — the method name the SDK will generate — prefilled from the node or flow name and editable inline. Aliases must be non-empty and unique within the client. 4. Click **Add N members**. The **Members** list groups node members by their package, with a **Remove all** per package and a **Remove** per member; flow members are listed individually. Removing members changes only future builds — an already-built version is never altered (see the next section). ## Build a version 1. In the **Build a version** section, select one or more languages — Python, Go, TypeScript, Java, C#, Rust. Every language you select shares **one version** of the bundle. 2. Click **Build**. The build allocates the next version number, snapshots the client's current members (with their pinned package versions), and compiles each selected language from that snapshot. The version appears in the **Versions** list with a per-language status — `pending`, `building`, then `succeeded` (or `failed`, with the error shown inline); the page refreshes statuses automatically. A version is an immutable snapshot: editing the client's members later never changes an existing version, only the next build. To add a language to an existing version, use the **+ language…** dropdown under that version. It compiles the new language from the version's frozen snapshot, so SDKs of the same version match exactly even if the client's members have changed since. ## Download and install the SDK Each succeeded language row has a **Download** button that saves a ZIP (for a client named `billing`, `billing-sdk-py.zip`). The ZIP is a ready-to-build package for the language's standard toolchain. Every SDK ships with a `README.md` covering install, authentication, and the full method list, and a `manifest.json` recording exactly which nodes, flows, and package versions the version contains. | Language | Typed messages come from | Install/build | |---|---|---| | Python | pregenerated protobuf modules (needs `protobuf>=4.0`) | `pip install -e .` | | Go | pregenerated protoc-gen-go types | `go mod tidy` | | TypeScript | protobufjs at runtime | `npm install && npm run build` | | Java | protobuf-java, compiled by Maven | `mvn package` | | C# | Google.Protobuf, compiled by Grpc.Tools | `dotnet build` | | Rust | prost + pbjson, compiled by Cargo | `cargo build` | ## Call the SDK No API key is embedded in a generated SDK. Every language's client reads the `AXIOM_API_KEY` environment variable at construction (or takes the key as an explicit constructor argument) and sends it as a bearer token on every request: ```bash export AXIOM_API_KEY="" ``` ```python # app.py — after installing the Python SDK of a client named "billing" from billing_sdk import Client client = Client() # reads AXIOM_API_KEY from the environment result = client.summarize(req) # one method per member, named by its alias ``` Methods take the member's typed input message and return its typed output message — the message classes are the generated protobuf types listed in the SDK's `README.md`. Method names derive from the alias in the language's own convention (`summarize_invoice` in Python and Rust, `summarizeInvoice` in Go, TypeScript, and Java, `SummarizeInvoiceAsync` in C#). A node member invokes that node directly by its human-readable URL (`/v1/nodes/{owner}/{package}/{version}/{node}`); a flow member invokes the flow's compiled artifact and returns its result. Pipeline (streaming) members return a stream of typed frames — a generator in Python, an async iterator in TypeScript, and the language's equivalent elsewhere. The deployment origin the SDK calls is baked in at build time from the deployment you downloaded it from; every constructor accepts a base-URL override for pointing the same SDK at another deployment. A `401` response means a missing, invalid, or revoked API key — see [API keys](../guides/api-keys.md).