Server and Client Model

The Developer SDK is deliberately split across server and client roles.

The core flow

What stays on the server

The server owns:

the Swig API key
wallet preparation calls
optional sponsor submission
any app-specific auth, request validation, and policy checks

The main entrypoint is:

TypeScript

import { SwigClient } from '@swig-wallet/developer-sdk/server/typescript';

from swig_developer_sdk import SwigClient

What reaches the client

The client should only receive prepared transaction payloads and their signature metadata. It should not receive the API key or call the Swig backend directly.

Why the response is split

Prepared responses are categorized so your app knows what to do next:

TypeScript / Python	What your app should do
`transactions`	submit these in order
`clientAuthorityTransactions` / `client_authority_transactions`	get a client authority signature first
`feePayerOnlyTransactions` / `fee_payer_only_transactions`	send or sponsor without client authority signing
`operatorSignedTransactions` / `operator_signed_transactions`	submit as-is after fee payer or sponsor handling

For recovery-enabled wallet creation, create(...) also returns creationTransaction / creation_transaction, addAuthorityTransaction / add_authority_transaction, configureRecoveryTransaction / configure_recovery_transaction, and sometimes recoverySetup / recovery_setup.

Wallet handles

The server-side wallet handle is how you move from “I know this wallet” to “I want to prepare actions for it”:

TypeScript

const wallet = swig.wallets.use({
  swigConfigAddress,
  walletAddress,
  requesterAuthority: {
    ed25519: {
      publicKey: userPublicKey,
    },
  },
});

wallet = swig.wallets.use(
    swig_config_address,
    requester_authority={
        "ed25519": {
            "publicKey": user_public_key,
        },
    },
)

If you already have an IDP session, the SDK also supports swig.wallets.fromIdpSession(session).

The client helpers

The client package is intentionally small:

signPreparedTransaction(...) / sign_prepared_transaction(...) for normal Ed25519 transaction signing
signPreparedSwigTransaction(...) / sign_prepared_swig_transaction(...) for passkey-backed Swig signature flows
passkey signing helpers such as createSecp256r1PasskeySigningFn(...) / create_secp256r1_passkey_signing_fn(...)

Use the browser and framework pages next if you want this split without writing all of the proxy glue yourself.

Start Here

Set Up Access

Build Wallet Flows

Add Recovery

Operate in Production

Workspace Admin

Server and Client Model

The core flow

What stays on the server

What reaches the client

Why the response is split

Wallet handles

The client helpers

​The core flow

​What stays on the server

​What reaches the client

​Why the response is split

​Wallet handles

​The client helpers

The core flow

What stays on the server

What reaches the client

Why the response is split

Wallet handles

The client helpers