Server SDKs

Language and framework options for integrating Company Wallets from a backend service.

Company wallet integrations are backend-driven. Your server creates wallets, constructs transactions, and signs them via the Turnkey API using an API key. This page covers that model, and choosing the right SDK for your stack.

Choose your SDK

TypeScript

Our most complete SDK. Recommended if your backend can run Node.js.

Go

Native Go SDK.

Ruby

turnkey_client gem for Ruby and Rails projects.

Rust

Native Rust SDK.

Python

Pydantic type definitions, an HTTP-client for easy direct requests, and API-key stamper.

Direct API

Call the Turnkey REST API directly from any language.

How server integrations work

All server integrations follow the same pattern regardless of language:

1. Create an API keypair on the Turnkey dashboard create an API user and save its credentials.
2. Initialize a client with your API credentials. The SDK handles request construction and signing.
3. Call the API — create wallets, sign transactions, manage policies — and receive results. For signing operations, only the signature is returned; private keys never leave the enclave.
4. Create policies scoping your API user to only its routinely performed functions.

This credential model is simpler than embedded wallets: there’s no end-user authentication, no sessions to manage, and no Auth Proxy. Your API private key lives on your server and signs every request.

API users and policies

API users are native to your organization. You can create multiple API users — one per service or environment — and scope each with policies that restrict what it can sign.

For example, a payment sweeper service might be allowed to sign outbound transfers up to a certain value, while a contract deployer has authority over a specific set of addresses. Turnkey is deny-by-default: if no policy explicitly allows an action, it is rejected.

See Policies for the policy language and Policy Quickstart to set up your first rules.

Organization structure

Most custodial integrations run within a single parent organization. Your org holds the wallets; your API users (backend services and human operators) act on them subject to policy.

If you need tenant isolation — for example, you’re building a product that provisions wallets on behalf of your customers — you can create sub-organizations, one per tenant, each with its own wallets and policies. See Sub-Organizations.