Skip to main content
If your app only needs a safe server-side proxy around transaction preparation, the SDK already ships it.

Use this path when

  • you want the API key to stay on the server
  • you want the SDK to wire the prepare routes
  • you still want browser code to work with wallet handles and prepared results

Next.js

Create one catch-all route:

NestJS

Create one controller mounted at your Swig proxy prefix:

Python

Create one handler, then adapt your framework’s request and response objects at the route boundary:
Return response.body with response.status from your framework route.

Routes the helpers cover

The framework helpers cover:
  • POST /wallet/create
  • POST /prepare
  • POST /transfer/sol
  • POST /transfer/spl-token
  • POST /swap/jupiter

Browser-side usage

Once your proxy exists, browser code can use SwigBrowserClient and call only your local app routes:
SwigBrowserClient is TypeScript-only. Python applications expose the proxy server-side and use their normal frontend stack for browser signing.
Then sign the returned prepared payload with the client helpers.

Server-side requester resolution

If your app does not include requesterAuthority in the browser request, the helpers let you resolve it server-side:
Use this when auth context or role mapping should stay on the server.