Smart Wallets

Offer smart wallets in your app: each user gets deposit addresses and one unified balance in your UI. Torque holds custody and routes settlement; you map your user id to their wallet. Cash-out and trades require explicit user consent today via Connect (v1 consent gate). Embedded branded consent is on the roadmap.

Private-Label Model

Torque is a digital wallet platform partners can white-label at the product layer: your brand, your signup, your balance and deposit screens. Provision and reads run on your server with a business API key. Onchain execution always requires user consent because Torque holds custody and your API key must never sign user transactions.

Surface	Your App	Torque
Provision, balance, deposits	Fully embedded in your app	Custody, addresses, portfolio READ, optional deposit webhooks
Cash-out, trade, transfer	Your app starts the flow; user approves consent (v1: Connect)	Signs only after consent; returns delegated JWT for POST /execute/**

Manage keys and setup in the developer portal.

Quick Start

#	Step	Action
1	API key	Portal → Overview → Create key. Server only.
2	Provision	POST /accounts/end-users with externalUserId + email
3	Deposits	Return addresses. Poll GET …/deposits or optional webhook in Settings
4	Cash-out	Settings → your app URL (https://yourapp.com). Add callback on your server
5	Test	Enable test cash-out in Settings before your app ships

Provision

Call on signup. externalUserId is your stable user id; email is their account email (required in v1 for Connect). Idempotent on externalUserId.

provision.sh

curl -sS -X POST "https://app.torque.fi/api/v1/accounts/end-users" \
  -H "Authorization: Bearer sk_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "externalUserId": "player_48291",
    "email": "user@example.com"
  }'

Response includes addresses, portfolioSummary, and capabilities. See Accounts API.

Deposits

Return addresses in your deposit UI. Encode each address in a client-side QR: QR value is the raw address string from addresses.evm, addresses.solana, or addresses.btcDeposit. No server QR endpoint.

Poll GET /accounts/end-users/{id}/deposits or set an optional deposit webhook in portal Settings (end_user.deposit.detected). Preview QR in the developer portal wallet row.

Cash-Out Setup

Connect is the v1 user consent gate, not the long-term private-label UX. Your app starts the flow and receives the callback; the user approves scopes on a hosted screen before Torque signs. Embedded branded consent is on the roadmap.

Stage	Model	Fit
v1 (shipped)	Connect OAuth	Correct custody boundary for launch. User signs in and approves on a hosted consent screen, then returns to your callback.
Roadmap	Scoped delegate sessions	Reuse consent after first approval; tighter scopes and amount caps without a full redirect every cash-out.
Roadmap	Embedded branded consent + partner attestation	Private-label cash-out UI in your shell; Torque validates partner-signed requests and optional user step-up.

Not supported: Mint wallet JWTs with sk_live_… alone; Unattended server sweeps without user or attested partner consent; Export seed phrases or owner keys to partners.

Portal → Settings → Cash-Out Setup → enter your app URL (e.g. https://yourapp.com). Torque registers callback https://yourapp.com/torque/connect/callback. Add that route on your backend. Users return with ?code=… after approving cash-out.

User approves on a consent screen, then returns to your app with a code. Exchange it on your server, then call execute APIs.

Test Cash-Out (Portal): try before your app is live. Callback: https://developers.torque.fi/connect/callback.

Who	Action
You	Save app URL in developer portal Settings
Your server	POST /connect/authorize/session (redirect_uri, PKCE, optional externalUserId)
User	Approves scopes on hosted Connect consent screen (v1)
Your server	Callback receives ?code=… → POST /connect/token
Your server	POST /execute/transfers/… with delegated JWT

Connect details: Connect OAuth, Actions: cash-out and execute, Authentication.

Identity & Recovery

The email you pass at provision is what the user signs in with when they approve a cash-out. Use a stable address your users will keep. externalUserId is how you look up the wallet in your systems. Email is how the user signs in for cash-out. Wrong email at signup means a separate account; balances are not merged between emails.

Support copy for lost devices: same email → same wallet (email code, passkey, or linked OAuth). Lost email access: contact hello@torque.fi for verified help, not self-serve. Details: Account Recovery for integrators.

FAQ

Is this a white-label or private-label wallet?

Yes at the product layer: your brand, signup, balance, and deposit UI. Torque provides custody, routing, and settlement under the hood. Cash-out consent is hosted in v1 (Connect); embedded branded consent in your shell is on the roadmap.

Why is Connect required for cash-out in v1?

Torque holds custody. Your business API key must never sign user transactions. Connect proves the end user approved scopes before Torque signs POST /execute/**. This is the launch-safe model; scoped delegate sessions and partner attestation are planned next.

Why is email required at provision?

Email is how the end user signs in when they approve cash-out consent. externalUserId is your player or account id for API lookups; email is the wallet sign-in identity.

How do deposits work?

Return addresses from provision in your UI. Encode each address in a client-side QR (EVM, Solana, or BTC). Poll GET …/deposits or configure an optional deposit webhook in portal Settings.

How does cash-out work?

Set your app URL in portal Settings. Your server starts Connect authorize; the user approves on the hosted consent screen (v1); your callback receives a code; exchange for a delegated JWT; call POST /execute/**. Your UI owns the withdraw button; Torque owns the consent and signing step until embedded consent ships.

What if a user loses email access?

Self-serve recovery stops. Escalate to your support team and Torque at hello@torque.fi for verified migration help. See Account Recovery for the full playbook.