Sign in to manage your organization.

Swivy dashboard access starts with an operator identity. After sign-in, create or join an organization, then configure projects, environments, API keys, chains, gas sponsorship, users, and wallets under that organization.

Email code HttpOnly session Org-scoped access

Work email Organization name Email code

Email-code dashboard auth

The API verifies the code, stores the session in an HttpOnly cookie, and returns only organizations where this operator is active. Operator passkeys use the browser or operating-system prompt: Face ID, Touch ID, Android passkeys, Windows Hello, or a hardware security key.

Swivy Control plane, hosted wallet surface, and customer integration handoff

Operator

Console

Same-origin proxy

API https://api.swivy.dev

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://api.swivy.dev

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

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

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.

Pick chains, wallets, and auth rules

Decide what users can create and sign with: EVM, Solana, passkeys, session rules, and gas policy.

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

4 Deploy app

Copy the publishable key, app ID, secret key, and SDK snippets into your app.

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.

Organization name Project name Environment name

Organization ID Project ID

Step 2: Choose Wallet Features

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

Enable gas sponsorship Sponsor EVM and Solana gas Use the wallet policy toggle above to let your app cover transaction costs for eligible users. Allow client transactions Client-side sponsorship Keep this off for production unless your backend rate limits and validates every sponsored operation.

Sponsored networks Max spend per user USD Max spend per day USD Allowed contract addresses

Save sponsorship policy changes.

These controls write to the environment policy. Client-side sponsorship stays disabled by default.

Webhook URL Webhook ID Last webhook secret

Webhooks registered for this environment

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 family Network RPC URL WebSocket URL RPC headers JSON Commitment

Feature status

Saved in offlineSigningPolicy.enabled. When off, SDKs reject offline envelope creation.

Transport status

Bluetooth mesh is treated as untrusted. Request envelopes should be signed with a pairing key and checked before signing.

Replay status

Signer clients cache signed request IDs and reject repeated packets before key reconstruction.

Native adapter package

Install @swivy/expo-bluetooth-mesh in the mobile app to provide the Bluetooth scan, advertise, permission, and packet-send layer.

App install command

npm install @swivy/expo @swivy/expo-bluetooth-mesh react-native-ble-plx

App wiring

import { createSwivyBluetoothMeshAdapter } from "@swivy/expo-bluetooth-mesh"; const swivy = await SwivyExpoClient.create({ ...config, bluetoothMeshAdapter: createSwivyBluetoothMeshAdapter() }); await swivy.startBluetoothMeshOfflineSigning({ onEnvelope });

Enable offline signing Offline transaction envelopes Expose Swivy request and response envelopes for transactions that are prepared online, signed locally, then relayed for broadcast. Bluetooth mesh Bluetooth mesh transport Allow app clients to advertise and relay offline signing envelopes over nearby Bluetooth mesh peers. QR fallback QR packet fallback Allow the same envelopes to move through QR handoff when mesh is unavailable or the user wants visual confirmation. NFC fallback NFC packet fallback Permit short-range NFC handoff for compact offline signing envelopes. File fallback File packet fallback Allow import/export of encoded envelope files for controlled field operations. Require split custody Self-custody only Keep offline signing limited to wallets that can reconstruct and sign on the user's device. Require passkey approval Passkey before signing Require a local passkey approval before an offline transaction envelope can be signed. Recovery package signing Allow local recovery package Permit fully offline reconstruction when the device has its local share plus a user-held recovery package.

Envelope TTL seconds

This toggle controls the Swivy feature surface. Online coordinators still need to prepare fresh nonce, fee, and blockhash data, and relays still need internet access to broadcast the signed payload.

Swivy RPC Infra is the primary provider.

The staging gateway is live at https://rpc-fabric-gateway-swivy-staging.onrender.com. It fronts an Alchemy-backed mixed model for EVM and Solana networks, while third-party providers remain selectable below when a customer needs direct routing or fallback coverage.

Status

Swivy RPC Infra First-party

Default data plane for chain reads, simulations, sends, wallet tools, and hosted environment routes.

Alchemy-backed routing

The hosted gateway can use Alchemy upstreams without exposing customer API keys in browser or dashboard fields.

Third-party fallbacks

Enable fallback providers for direct Alchemy, QuickNode, Helius, or custom endpoints when needed.

Enable RPC provider Use RPC Infra gateway Route Swivy chain reads, simulations, sends, and wallet tools through your RPC Infra deployment when configured. Fallback RPC providers Use backup RPC routes Allow lower-priority external RPC providers or saved chain routes when RPC Infra has no healthy upstream. Auto-import networks Import from descriptor Let Swivy pull the project network matrix from RPC Infra's descriptor/export flow instead of manually entering each URL.

Primary RPC provider RPC Infra control plane URL RPC Infra data plane URL RPC Infra project ID Project secret ref Gateway status URL

Provide	Network	Family	Chain ID	RPC URL override
	ethereum-mainnet	evm
	base-mainnet	evm
	arbitrum-mainnet	evm
	optimism-mainnet	evm
	polygon-mainnet	evm
	base-sepolia	evm
	ethereum-sepolia	evm
	tempo-testnet	evm
	solana-mainnet	solana
	solana-devnet	solana

Use Swivy 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.

Enable blockchain data API Portfolio and explorer reads Allow Swivy clients and agents to request enriched balances, NFTs, token metadata, prices, and transaction history. Fallback providers Use backup sources Let Swivy try lower-priority providers when the primary source is missing a route or market.

Primary provider Solscope URL Helius URL Solscan URL Jupiter URL Custom URL

Solscope First-party data layer Use the Solscope codebase integrated with Swivy for Helius/Etherscan-style chain data. Helius External Solana API Optional third-party fallback for Solana balances, NFTs, DAS, and webhooks. Solscan External explorer API Optional fallback for Solana explorer-style account and token data. Jupiter External market/swap data Optional fallback for Solana token and route data; swaps remain controlled by wallet tool policy. Custom Your own API Use another internal blockchain data provider while keeping the same Swivy policy shape.

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 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.

Credential label Credential ID

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.

Advanced policy JSON

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.

Organization ID Invite email Invite role Invite expiry (hours)

Member ID Member role Invite ID Admin credential ID

New admin key label New admin key role Last invite token Last admin key

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.

Project ID Project name Environment ID Environment name

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.

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

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.

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.

1. Get credentials

Open Keys, issue an environment keypair, then copy the App ID plus publishable key into your frontend and the secret key into your backend.

2. Install SDKs

Use @swivy/web in browser apps and @swivy/node in backend jobs, API routes, and agents.

npm install @swivy/web @swivy/node

3. Verify users

After the first login, open Users to confirm the app user email, external user ID, embedded wallets, linked wallets, and recent intents.

Public URLs

1
Console URL: give this to customer developers so they can create keys, inspect users, read docs, and test wallets.
2
API URL: use this in SDK config and backend requests. Current proxied API is https://api.swivy.dev.
3
Docs URL: share /docs for the OpenAPI-backed reference and this tab for the shortest integration checklist.

What your app users get

1
Email-code login creates a Swivy identity in this environment.
2
Wallet bootstrap can auto-create EVM and Solana embedded wallets under that identity.
3
The dashboard user directory shows email, external user ID, managed wallets, linked wallets, custody mode, sessions, and intents.

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.

Issuer origin Client name Token auth method Application type Client ID Last client secret

Redirect URIs Scopes

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.

Console callback URI

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

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.

App ID Publishable key Session token

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.

Save or load app credentials, then load signup readiness.

Email login Email Users verify a code sent to their email address. Local dev writes the code to API logs. SMS login SMS Mirrors the environment SMS recovery toggle. Use Policies to save this to the environment. Passkey MFA Passkeys Enable WebAuthn step-up for signing, wallet reconstruction, exports, and delegated session grants. External wallets External wallets Linked wallet support is tracked separately from embedded managed wallets.

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.

Passkey label

No passkey enrollment started.

Sign in a test user

Email External user ID Email code

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.

Wallet purpose New wallet custody

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.

Signing keys

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

3E: Prepare Self-Custody

Account ID Device commitment Recovery commitment

Device encrypted payload Recovery encrypted payload

Recovery package

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

Account ID Label Challenge ID Expires in seconds Max uses Max tx value USD

Allowed networks Allowed signing kinds

Allow execute_transaction

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

Label Auth method ID Code

No TOTP enrollment started.

SMS Enrollment

Label Phone number Auth method ID Challenge ID Code

No SMS enrollment started.

Passkey Enrollment

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

Approval Challenge

Active auth method Purpose Code

No challenge created.

Signing

Account ID Chain Challenge ID

Message

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

EIP-712 typed data JSON

Execute Transaction

Account ID Chain Network Challenge ID

Request sponsorship when available Transaction payload JSON

Hosted Output

Ready.

Sign in to manage your organization.

Get started

Connect Swivy to your app.

Your integration path

What you copy into your app

Overview

Recommended next steps

Create your Swivy app

What this setup gives you

Step 2: Choose Wallet Features

Wallet feature controls

Gas sponsorship

Webhooks

Webhooks registered for this environment

Email delivery

Recommended: HTTP provider

SMTP provider

Chain routes

Offline signing

RPC Infra

Blockchain data sources

API keys

Advanced policy JSON

Swivy operator admin

Organization Access

Organization Context

Organization Workspace

Workspace Stats

Projects and Environments

Organization Members

Organization Invites

Organization Admin Keys

Environment Snapshot

Step 4: Deploy Handoff

Integrations

Integration Bundle

Wallet Deploy Smoke

Terminal Smoke Command

Passkey Split-Custody Smoke

Staging Smoke Commands

Docs and integration guide

Frontend quickstart

Backend quickstart

Quickstart Env Vars

Web SDK Snippet

Node SDK Snippet

Launch Readiness

OIDC / Sign in with Swop

OIDC Integration

Session Grants

Users

Customer user directory

User Detail

Credentials

Chain Targets

Recent Intents

Webhooks

OIDC Clients

Audit Log

Admin Output

Step 3: Test the Wallet Flow

3A: App Config

3B: Privy-style signup readiness

User authentication

Passkey enrollment

Sign in a test user

Wallets

Authorization

Signing keys

3E: Prepare Self-Custody

Optional: Backend Session Grant

TOTP Enrollment

SMS Enrollment

Passkey Enrollment

Approval Challenge

Signing

Execute Transaction

Hosted Output