> ## Documentation Index
> Fetch the complete documentation index at: https://docs.turnkey.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

<CardGroup cols={2}>
  <Card title="TypeScript" icon="js" iconType="solid" href="/solutions/company-wallets/integration-guide/javascript-server">
    Our most complete SDK. Recommended if your backend can run Node.js.
  </Card>

  <Card title="Go" icon="golang" iconType="solid" href="/solutions/company-wallets/integration-guide/golang">
    Native Go SDK.
  </Card>

  <Card title="Ruby" icon="code" iconType="solid" href="/solutions/company-wallets/integration-guide/ruby">
    turnkey\_client gem for Ruby and Rails projects.
  </Card>

  <Card title="Rust" icon="rust" iconType="solid" href="/solutions/company-wallets/integration-guide/rust">
    Native Rust SDK.
  </Card>

  <Card title="Python" icon="python" iconType="solid" href="/solutions/company-wallets/integration-guide/python">
    Pydantic type definitions, an HTTP-client for easy direct requests, and API-key stamper.
  </Card>

  <Card title="Direct API" icon="code" iconType="solid" href="/api-reference/overview/intro">
    Call the Turnkey REST API directly from any language.
  </Card>
</CardGroup>

## 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](/features/policies/overview) for the policy language and
[Policy Quickstart](/features/policies/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](/features/sub-organizations).