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

# Server and Client Model

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

## The core flow

```mermaid theme={null}
flowchart LR
  A["Server with API key"] --> B["Prepare wallet operation"]
  B --> C["Return prepared transaction(s)"]
  C --> D["Client signs required transactions"]
  D --> E["App sends directly or sponsors submission"]
```

## 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:

<CodeGroup dropdown>
  ```typescript TypeScript theme={null}
  import { SwigClient } from '@swig-wallet/developer-sdk/server/typescript';
  ```

  ```python Python theme={null}
  from swig_developer_sdk import SwigClient
  ```
</CodeGroup>

## 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":

<CodeGroup dropdown>
  ```typescript TypeScript theme={null}
  const wallet = swig.wallets.use({
    swigConfigAddress,
    walletAddress,
    requesterAuthority: {
      ed25519: {
        publicKey: userPublicKey,
      },
    },
  });
  ```

  ```python Python theme={null}
  wallet = swig.wallets.use(
      swig_config_address,
      requester_authority={
          "ed25519": {
              "publicKey": user_public_key,
          },
      },
  )
  ```
</CodeGroup>

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.