Skip to main content
Swig has three TypeScript surfaces related to the developer portal. They overlap, but they are not the same product.

​
Client comparison

The current SDK also ships a Python package, swig-developer-sdk, at the same version and with the same surface. The other two are TypeScript-only. Use @swig-wallet/developer-sdk or swig-developer-sdk first if your goal is to:
  • create wallets through backend-prepared transactions
  • keep the API key on the server
  • read wallet balances, activity, and roles
  • build authenticated Next.js, NestJS, Fetch, or Python server routes around Swig actions
  • submit transactions signed by application-owned wallet or custody code

​
When to use the other two

  • Use @swig-wallet/api when you mainly want raw REST access to policies, wallet create endpoints, or paymaster endpoints.
  • Keep @swig-wallet/developer only for existing integrations that already depend on its richer policy helpers.
Treat @swig-wallet/developer as deprecated for new integrations.

​
Policy nuance

@swig-wallet/developer-sdk does expose swig.wallets.getPolicy(policyId), but that does not make it the rich policy-helper SDK. It returns raw policy metadata because wallet creation flows need that metadata. If you need helpers like Actions.canSpendSol() or AuthorityInfo.isSession(), that is still legacy @swig-wallet/developer territory.

​
Not the protocol SDK

None of these three are the protocol SDK. If your app talks to Swig wallets directly and owns its own authority and signing flow, use the Protocol SDK instead.