Skip to main content
This guide shows how to create Swig wallets programmatically using the Developer Portal API. This approach is ideal for applications that need to create wallets on behalf of users with predefined policies.
This page covers the direct developer-portal API clients @swig-wallet/api and @swig-wallet/developer. If you want the newer prepare-first SDK in swig-ts/packages/developer-sdk, start with What the Developer SDK Does. Treat @swig-wallet/developer as the legacy developer SDK for existing integrations.

When to Use the API

Use the Portal API when:
  • Creating wallets from a backend service
  • Using predefined policies from the Developer Portal
  • Leveraging the paymaster for sponsored wallet creation (optional)
  • You want to build the transaction server-side but sign and send it client-side
  • Managing wallets at scale
Use the direct protocol SDKs when:
  • Building client-side applications
  • Users control their own keypairs
  • You need full control over wallet configuration
  • Not using the Developer Portal policies
For direct SDK wallet creation (without the Portal API), see the Creating a Swig tutorial.

Prerequisites

Before creating wallets via the API, ensure you have:
A paymaster is optional. When you omit paymasterPubkey, the API returns an unsigned transaction instead of submitting it on-chain. You can then sign and send the transaction yourself. See Creating Without a Paymaster below.

Installing a Portal Client

Current Swig Developer SDK

If you are starting a new server-assisted integration, prefer @swig-wallet/developer-sdk over @swig-wallet/developer. The current package is prepare-first:
  1. your server uses an API key
  2. the server prepares wallet transactions
  3. the client signs only the required transactions
  4. your app submits them directly or through a sponsor flow
Minimal server-side example:
Use this page when you specifically want the developer-portal create-wallet endpoint or its older portal clients. Use What the Developer SDK Does for the current product surface. For the current hosted operation flows after wallet creation, see Transfers and Swaps and Recovery.

Specifying the Wallet Authority

When creating a Swig wallet, you need to define the authority (signer) that will control it. There are two ways to do this: Option 1: Using a Signer ID from the Dashboard If you’ve already created a signer in the Developer Portal dashboard (or your policy has one attached), you can reference it by its signerId. This is the original approach and is useful when you manage signers centrally through the portal. Option 2: Providing a Wallet Address and Type Directly You can supply a walletAddress (the public key) and walletType (the authority type) at creation time instead of using a signer ID. This lets you skip creating a signer in the dashboard entirely — useful when your application already knows the user’s public key and authority type.
Provide either signerId or the walletAddress + walletType pair. When your policy already has a signer attached and both inputs are omitted, the policy’s signer is used by default.

Supported Wallet Types

When using the walletAddress + walletType approach, the following types are supported:
For session types (ED25519_SESSION, SECP256K1_SESSION, SECP256R1_SESSION), you must also provide the maxDurationSlots parameter to specify how long the session authority remains valid.

Creating a Swig Wallet

Using the REST API

Make a POST request to the wallet creation endpoint:
You can also supply the wallet authority directly instead of relying on a signer from the dashboard:
Example Response:

Using a Portal Client

With Wallet Address and Type

You can also provide a walletAddress and walletType directly instead of relying on a signer configured in the dashboard:

Portal Client Comparison

Request Parameters

Required Parameters

Optional Parameters

Response Fields

The response shape depends on whether a paymaster was provided.

With Paymaster

Without Paymaster

When no paymaster is used, the expected swig address is still recorded in the Developer Portal database so you can track and manage it through the dashboard.

Creating Without a Paymaster

When you omit paymasterPubkey, the API builds the create-swig transaction but does not send it. Instead, it returns a base58-encoded serialized VersionedTransaction that you can deserialize, sign, and send yourself. This is useful when:
  • Your users pay their own transaction fees
  • You want to collect multiple signatures before sending
  • You prefer to manage fee payment directly

Using the REST API (No Paymaster)

Example Response:

Using the SDK (No Paymaster)

When using the no-paymaster flow, the returned transaction includes a recent blockhash. Blockhashes expire after approximately 60-90 seconds. You must sign and send the transaction promptly.

Examples

Basic Wallet Creation

With Custom Swig ID

With Signer Override

If your policy doesn’t have a signer attached, or you want to use a different signer from the dashboard:

With Wallet Address and Type

Instead of creating a signer in the dashboard and referencing it by ID, you can supply the wallet’s public key and authority type directly at creation time:

With Session Authority

For session-based authority types, include maxDurationSlots to set the session lifetime:

Production Wallet

Error Handling

Common Errors

Complete Example

TypeScript Types

Legacy SDK Types

The legacy @swig-wallet/developer SDK provides higher-level types that automatically reconstruct the transaction:

Comparison: Portal API vs Direct SDK

Next Steps

After creating a wallet, you can: