Skip to main content

Documentation Index

Fetch the complete documentation index at: https://turnkey-0e7c1f5b-graham-docs-revamp.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

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.