S
Swivy Control plane, hosted wallet surface, and customer integration handoff
Operator
Console
Same-origin proxy
API https://swivy-api.onrender.com
Developer dashboard

Get started

Create your app, choose wallet rules, test a user, then copy the SDK snippets into your product.

Surface: Customer dashboard
Developer onboarding

Connect Swivy to your app.

Create a Swivy environment, choose the wallets and chains your app supports, test sign-in as an end user, then copy the generated keys and SDK snippets into your frontend and backend.

Proxied API: https://swivy-api.onrender.com
Use the guided path first. The detailed controls below are for editing the same app, keys, users, wallets, policies, and integrations after setup.
API Docs OpenAPI JSON Claude Console Preview Claude Marketing Preview
Start here: make Swivy usable inside your product.
The setup creates a developer account, app environment, publishable key, secret key, wallet policy, and test chain routes. After that, the integration page gives you copy-paste SDK code.

Your integration path

Swivy has two surfaces: this dashboard for your team, and the API/SDK your app calls for your users. Follow these three steps before touching the advanced controls.

1 Create your app
Creates the organization, project, environment, App ID, publishable key, and backend secret.
2 Choose wallet rules
Enable EVM and/or Solana, decide custody behavior, allowed origins, and gas sponsorship.
3 Test as a user
Sign in with an email code, create wallets, inspect users, and confirm wallets are attached.

What you copy into your app

Once setup is complete, use the Integrations section as your handoff checklist.

  • Frontend
    App ID and publishable key for Swivy Web SDK login and embedded wallet creation.
  • Backend
    Secret key for server-side API calls, webhooks, and controlled admin operations.
  • Users and wallets
    The Users page shows user email, identity ID, linked wallets, managed wallets, and custody status.
App-side shape createSwivyClient({ appId, publishableKey })
Exact values appear after setup under Integrations.

Overview

Total users 0
Loaded from this environment dashboard.
Total wallets 0
EVM, Solana, linked, and managed accounts.

Recommended next steps

1
Create or load your app environment
This is the thing your product integrates with. It gives your app public browser credentials and a private server credential.
2
Pick chains, wallets, and auth rules
Decide what users can create and sign with: EVM, Solana, passkeys, session rules, and gas policy.
3
Copy SDK snippets into your app
Use Integrations for the browser SDK, Node SDK, OIDC callback, API URL, App ID, publishable key, and secret key.
1 Create app
Create or load the Swivy environment that will issue wallet sessions for your app.
2 Enable chains
Apply the self-custody policy and configure safe EVM plus Solana RPC targets.
3 Test wallets
Sign in like a user, create EVM and Solana wallets, enroll passkey step-up, and sign locally.
4 Deploy app
Copy the publishable key, app ID, secret key, and SDK snippets into your app.

Create your Swivy app

This is the app record your product uses for login, wallets, policies, users, and API keys.

Recommended: run first-run setup Fastest path
This creates your organization, project, development environment, app policy, EVM/Solana test routes, App ID, publishable key, and secret key in one step.

What this setup gives you

Use the generated credentials in your own frontend and backend. Your app users sign in through your UI, then Swivy creates and manages their wallets under this environment.

You are signed in as the dashboard operator.
The operator owns the organization. End users are separate; they appear under Users after they sign into your app or the hosted test flow.
Setup checklist
  • 1
    Click Create my app. Keep the default development names unless you already know your production naming.
  • 2
    Open Integrations and copy the frontend and backend snippets into your app.
  • 3
    Open Test user flow, sign in as a test user, create wallets, then confirm that user and wallet appear in Users.
Create or load an environment to get the exact setup completion checklist, SDK keys, and app handoff links.

Step 2: Choose Wallet Features

Turn on the chains and runtime features your app should expose, then save them to the environment.

Wallet feature controls

Saving toggles updates the environment policy and applies testnet RPC routes for the enabled chains. The JSON below stays visible as the advanced view of the same settings.

Gas sponsorship

Choose whether Swivy can pay network fees for users and which networks are eligible.

Available credits: local
Sponsor walletMissing
Configure SWIVY_GAS_SPONSORS_JSON for each sponsored network.
Network--
Saved from the sponsored network allowlist.
BalanceUnknown
Live balance checks require deployment-level sponsor wallet config.
Remaining transactionsUnknown
Estimated after balance telemetry is connected.
Save sponsorship policy changes.
These controls write to the environment policy. Client-side sponsorship stays disabled by default.

Webhooks

Register backend endpoints that receive signed Swivy auth, wallet, and intent events.

Webhooks registered for this environment

Email delivery

Send dashboard and end-user login codes to a real inbox instead of Render or Docker logs.

Load an environment to inspect whether this deployment is using log, HTTP, or SMTP code delivery.

Recommended: HTTP provider

Use this when you have an email service webhook, worker, or transactional email endpoint. Render stores the token as a secret env var.

SMTP provider

Use this for SendGrid, Postmark, Resend SMTP, Mailgun, or any hosted SMTP mailbox provider.

Where to set this on Render
  • 1
    Open Render, choose swivy-api, then open Environment.
  • 2
    Set either the HTTP env vars or the SMTP env vars below, then keep SWIVY_LOG_CODES=false.
  • 3
    Redeploy swivy-api, refresh this page, and request a new email code.

Chain routes

Configure the RPC routes Swivy will use for the enabled EVM and Solana networks.

RPC provider

Choose the first-party RPC Infra deployment and the chains this Swivy environment should provide.

RPC Infra first-party
Provide Network Family Chain ID RPC URL override
base-mainnet evm
arbitrum-mainnet evm
tempo-testnet evm
solana-mainnet solana
solana-devnet solana
Use RPC Infra's /api/provider/v1/projects/:projectId/descriptor or /api/control-plane/projects/:projectId/swivy-export as the source for live URLs. Secret values stay in deploy env vars; this policy stores only secret names.

Blockchain data sources

Choose where Swivy reads portfolio, token, NFT, price, search, and explorer data.

Solscope first-party
API keys are stored as deploy secrets. Put secret names in policy only when needed; do not paste provider keys into this console field set.

API keys

Create and manage credentials: a publishable key for your frontend and a secret key for your backend.

API key management
  • 1
    Rotate keypair creates a publishable key for your frontend and a secret key for your backend.
  • 2
    The secret is shown once in Admin Output and the Integration Bundle, then the credential ID is used for revoke/rotation.
  • 3
    Use Revoke keypair when a key is leaked or an app environment should stop accepting that key.

Advanced policy JSON

Use swop-self-custody for the current Swop posture: email bootstrap, passkey step-up, split_custody wallets, no SMS, and no sponsorship. Use the toggles for normal operation, and edit JSON only when you need an advanced policy value.

Swivy operator admin

This is the internal management surface for Swivy support and platform operations. Customer developers should use Get started, Users, Wallets, API keys, and Docs.

Hidden from public ops by default
Operator workflows
  • 1
    Inspect a customer organization, project, or environment without asking the developer to copy internal IDs repeatedly.
  • 2
    Use organization access controls for support, invites, and scoped admin credentials.
  • 3
    Keep emergency credentials separate from the customer dashboard and scoped to the smallest needed operation.
Public URL split
  • 1
    swivy-console is where customers get API keys, manage users, inspect wallets, and read docs.
  • 2
    swivy-api is what customer apps and SDKs call.
  • 3
    An internal admin deployment should use SWIVY_CONSOLE_SURFACE=internal_admin and stronger access controls.
Advanced tenant and organization controls live below.
Open the disclosure when you need support tools. The normal developer dashboard keeps them out of the first-run path.
Advanced tenant and organization controls

Organization Access

Manage enterprise operators, org-scoped admin keys, and invite flows from the same environment context.

Load an environment or enter an organization ID to inspect org access state.

Organization Context

Use the row actions below to prefill member, invite, and admin-key controls before making changes.

Organization Workspace

Browse projects and environments without manually chasing IDs through separate API calls.

Load an organization to explore its projects and environments.

Workspace Stats

Select a project to prefill environment creation, or open an environment to refresh the full admin dashboard.

Projects and Environments

Organization Members

Organization Invites

Organization Admin Keys

Environment Snapshot

Step 4: Deploy Handoff

Once the Test Wallets checklist is green, copy these into your app and deploy your own frontend/backend.

Frontend
Use the App ID and publishable key with the browser SDK to sign users in and create embedded wallets.
Backend
Use the secret key server-side for controlled environment operations, webhooks, and agent session grants.
Chains
Keep EVM and Solana RPC targets configured before moving from testnets to production networks.

Integrations

Connect the Swivy environment to your app, backend, auth surfaces, and chain providers.

Embedded wallets
Use the Web SDK with your App ID and publishable key to create EVM and Solana wallets.
WalletConnect project ID
Add your WalletConnect project ID when external wallet sign-in becomes part of this app.
OIDC / Sign in with Swivy
Create issuer clients so another app can use this environment as an identity provider.
Conduit or custom rollup RPC
Register custom chain routes under Policies when your app needs a dedicated EVM network.
LI.FI swaps Enabled
Runtime users and agents can request EVM or cross-chain swap quotes at /v1/runtime/tools/lifi/quote. Swivy checks walletToolPolicy token allowlists, max value, max slippage, and the normal execution approval path.
Jupiter swaps Enabled
Solana wallets can request Jupiter quotes and optional serialized swap transactions at /v1/runtime/tools/jupiter/quote. Mint allowlists, value caps, slippage caps, and MFA are enforced before execution.
Hyperliquid perps Planned
Perps need market allowlists, leverage caps, daily loss limits, and expiring agent delegation before Swivy should let a deployed wallet trade them.
Polymarket orders Planned
Prediction-market tools need jurisdiction gating, market allowlists, order-size caps, and passkey step-up before order signing is turned on.

Integration Bundle

Create or load an environment to see the exact runtime and control-plane credentials for a customer handoff.

Wallet Deploy Smoke

End-to-end proof for a Swivy ID: email login, agent EVM wallet, agent Solana wallet, split-custody browser requirement, tool guardrails, and a mock EVM execution intent.

Load an environment and sign in a test user to inspect wallet deploy smoke readiness.

Terminal Smoke Command

npm run smoke:wallet-deploy
This creates a disposable organization/environment in the local API, signs in by email code from Docker logs, activates managed TEE agent wallets on EVM and Solana, verifies split-custody needs browser shares, checks LI.FI/Jupiter policy blocking, and broadcasts a signed mock EVM transaction.

Passkey Split-Custody Smoke

Acceptance proof for personal self-custody wallets: passkey approval unlocks wallet reconstruction, then EVM and Solana messages are signed locally from browser/device shares.

npm run smoke:passkey-split-custody
This uses the deterministic passkey-import API for automation. The in-browser Enroll passkey button still uses native WebAuthn prompts for real users.

Staging Smoke Commands

SWIVY_STAGING_API_URL=https://api.staging.example.com \ SWIVY_ADMIN_TOKEN=... \ SWIVY_EMAIL_CODE_COMMAND='node tools/read-staging-email-code.mjs --email "$SWIVY_SMOKE_EMAIL"' \ SWIVY_EMAIL_INBOX_URL='https://mailbox.example.com/messages?to={encodedEmail}' \ SWIVY_EMAIL_INBOX_AUTH_TOKEN='Bearer ...' \ npm run smoke:staging-wallet-deploy SWIVY_STAGING_API_URL=https://api.staging.example.com \ SWIVY_ADMIN_TOKEN=... \ SWIVY_EMAIL_CODE_COMMAND='node tools/read-staging-email-code.mjs --email "$SWIVY_SMOKE_EMAIL"' \ SWIVY_EMAIL_INBOX_URL='https://mailbox.example.com/messages?to={encodedEmail}' \ SWIVY_EMAIL_INBOX_AUTH_TOKEN='Bearer ...' \ npm run smoke:staging-passkey-split-custody
The built-in email reader polls an HTTP test inbox for $SWIVY_SMOKE_EMAIL and prints the newest six-digit code. The staging smoke scripts also read .env.staging, so CI can keep these values in secret env instead of pasting them into the command.

Docs and integration guide

Use this page as the product-facing handoff: where users get keys, how your app calls Swivy, and how to verify wallets after launch.

API Docs OpenAPI
Customer dashboard mental model
  • 1
    API keys are where a developer copies browser and server credentials for their app.
  • 2
    Users is where they inspect their app users, emails, linked wallets, managed wallets, and recent intents.
  • 3
    Wallets is where they test the same embedded wallet flow their app will run.
Swivy operator mental model
  • 1
    Developer dashboard is the public customer surface. It should never expose break-glass credentials.
  • 2
    Internal admin is a separate console surface for support, customer org inspection, platform health, and emergency scoped access.
  • 3
    Render deploys the API and console as separate URLs. Customers use the console URL; apps call the API URL.

Frontend quickstart

Load or create an environment, then use the Web SDK snippet below this page.

Backend quickstart

Issue an API key, then use the Node SDK snippet below this page.
Keep this docs page narrow.
This is the page a developer should understand first. Advanced JSON policy, org access, webhooks, and chain routing remain in Settings.

Quickstart Env Vars

Create or rotate an environment keypair to reveal the full publishable and secret keys.

Web SDK Snippet

Load an environment to generate a browser integration snippet.

Node SDK Snippet

Load an environment to generate a backend integration snippet.

Launch Readiness

Computed from the loaded environment policy, chain routes, runtime keys, webhook state, OIDC clients, and signer trust.

Load an environment to inspect launch readiness.
Current posture
Load an environment to inspect signer and custody posture.

OIDC / Sign in with Swop

Create issuer clients on this environment so another app can use Swop as its login provider and then exchange that identity into its own runtime session.

Use none for public PKCE clients. Confidential server-side clients should use one of the client-secret methods.

OIDC Integration

Load an environment to generate issuer discovery, JWKS, and exchange URLs.
Load an environment to generate a relying-party integration snippet.
The tester drives the proxied /oidc/* flow end to end. If this client uses a secret, keep the latest client secret available before starting the popup test.
No hosted OIDC auth test run yet.

Session Grants

Users

Inspect users, auth methods, and wallet records created through this Swivy environment.

Active users 0
Users with environment activity, including sessions, wallets, linked wallets, or intents.
Total users 0
Customer identities returned by the environment dashboard.

Customer user directory

Load the environment dashboard to see each app user, email, external user ID, auth factors, embedded wallets, linked wallets, session grants, and recent wallet intents.
Load an environment to see users and wallet state.

User Detail

Select a user from the left to inspect auth methods, wallets, and recent intents.

Credentials

Open API keys to manage environment credentials.

Chain Targets

Open Policies to manage chain routes.

Recent Intents

Webhooks

Open Webhooks to manage event endpoints.

OIDC Clients

Audit Log

Admin Output

Ready.

Step 3: Test the Wallet Flow

Use this as the acceptance pass before deploying: sign in as a user, create both embedded wallets, add a passkey, then prove the browser can sign with the local share.

How to prove this works inside your app
  • 1
    Copy the App ID and publishable key from Integrations into your frontend.
  • 2
    Run the same sequence here that your app will run: request email code, verify user, create EVM wallet, create Solana wallet.
  • 3
    Refresh the admin dashboard. The user and both wallets should appear under Users, proving Swivy issued real runtime wallet records for the app.
Local email codes are written to the API logs. Run docker compose -f compose.dev.yaml logs api | rg "Issued verification code", then paste the six-digit code into Email Login.

3A: App Config

These are the publishable credentials your frontend will use. The local setup wizard fills them automatically.

The current hosted UI uses email bootstrap plus runtime session APIs, matching the app-side integration path in Swop. If you used the local test setup, these credentials are already filled.

3B: Privy-style signup readiness

Check whether this environment is configured for email login, passkey step-up, and split-wallet auto-provisioning.

Save or load app credentials, then load signup readiness.

User authentication

Configure the auth posture and run a live email sign-in test.

Passkey enrollment

After a test user signs in, enroll a passkey here to prove Swivy can gate wallet signing and self-custody unlocks with WebAuthn.

No passkey enrollment started.

Sign in a test user

Wallets

Create and inspect embedded EVM and Solana wallets for the signed-in test user.

Ready for wallet testing Sign in with the email-code flow first, then create an EVM or Solana wallet. This panel will show the result immediately.
Total assets $0
Local test wallets do not query live balances yet.
Total wallets 0
Managed accounts visible in the current runtime session.
Custody mode --
Default mode used when creating wallets below.
Use personal + split_custody for browser-held self-custody. Use agent + managed_tee for terminal, backend, and agentic flows. Swivy can keep both wallet types on the same chain.
Sign in to see embedded wallets.

Authorization

Manage the signing keys and user factors that authorize wallet operations.

Signing keys

Server signing keys are managed through API keys in local development. User passkeys, TOTP, and SMS factors appear below after sign-in.
Sign in to enroll passkeys, TOTP, and SMS factors.

3E: Prepare Self-Custody

For a Privy-style browser wallet, create it from the wallet composer above with split_custody. Prepare self-custody will select or create the browser wallet, make sure a passkey exists, and open a wallet_reconstruction unlock. This panel also lets you migrate a signer-backed wallet into legacy split-custody metadata or reconstruct a local export using the saved device share plus the server share.
No split-custody update submitted.

Optional: Backend Session Grant

This generates an Ed25519 session key in the browser, registers the public key with Swivy, and returns the private key PEM once so you can hand it to a backend agent using @swivy/node.
No delegated session grant created.

TOTP Enrollment

No TOTP enrollment started.

SMS Enrollment

No SMS enrollment started.

Passkey Enrollment

Open User authentication to enable and enroll passkeys for the signed-in test user.

Approval Challenge

No challenge created.

Signing

If no valid wallet_reconstruction unlock is active, the local-sign buttons will now prepare self-custody automatically and continue with the signature.

Execute Transaction

Hosted Output

Ready.