Docs

Quickstarts

Choose a verified Torq Developer Preview path for canonical reads, signed workflows, or events.

All Torq developer capabilities currently require Developer Preview admission. Start with the path that matches your product boundary; do not put a server secret in browser code and do not use RPC to recreate shared Torq state.

What is executable today

You need toStart hereCompletion check
Launch a complete institutional Earn experienceFew-line Earn quickstartCatalogue loads and reviewed writes reach final_success
Create a preview organization and initial keysPreview onboardingAn organizationId, applicationId, and one-time credential handoff
Read canonical markets, vaults, or positionsRead canonical stateA response with items, pageInfo, and freshness
Deploy a vault, deposit, or borrow with an approved roleWorkflow quickstartsfinal_success after canonical readback
Receive product updatesWebhooks and eventsA verified, deduplicated event envelope
Test without production authorityTesting and sandboxA ready sandbox and the requested canonical lifecycle status

Before you begin

You need an approved Developer Preview application, the matching environment credential, and a Sepolia wallet only when the workflow requires a customer-owned on-chain signer. A basic read-only integration does not need a wallet signature.

Use Authentication and scopes to choose the right credential. The few-line Earn quickstart provides the minimal TypeScript path and explains the expected canonical response.

Preview onboarding and credentials

Creating an organization is Developer Preview only. Torq issues the preview invitation out of band; it is not a public signup token and must remain in your server-side secret manager. The bootstrap response is the only time the initial test keys are returned.

curl -X POST https://api.torq.finance/v1/organizations \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: org-bootstrap-REPLACE_ME' \
  -H 'x-torq-preview-invite: torq_preview_invite_REPLACE_ME' \
  --data '{
    "name": "Example Wallet",
    "applicationName": "Example Wallet Sandbox",
    "origin": "https://sandbox.example-wallet.test",
    "ownerWalletAddress": "0xREPLACE_WITH_OWNER_WALLET"
  }'

Store secretKey only in your server secret manager, register the returned publishable key only for its approved browser origin, and save organizationId and applicationId as non-secret application configuration. The success response has environment: "test", keysShownOnce: true, and releaseStatus: "private_preview".

To create a scoped replacement key later, call POST /v1/keys from your server. List, rotate, and revoke keys from the lifecycle guide; no browser flow is authorized to create or rotate a secret key.

Permissioned workflows

The following are real private-preview workflow families. They remain conditional on the current wallet, network, application scope, canonical role state, and action-specific freshness proof.

OutcomeWorkflow typeWho may prepare itSuccess check
Deploy a V2 vaultrole.asset_manager.vaultDeployCurrent Asset Manager with DEPLOY_VAULTSDeployed runtime and canonical vault record pass the prepared postconditions
Deposit to a vaultdepositWallet and vault rules determine eligibilityThe tracked workflow reaches final_success
Borrow from a marketborrow or role.borrower.borrowerBorrowCurrent Borrower role and market authorityThe tracked workflow reaches final_success
Subscribe to eventsPOST /v1/stream-token, then WebSocketServer-side secret key; application event scopeFirst event is deduplicated and cursor is persisted

Deploy a vault

Use canonical addresses and entity IDs returned by Torq. Do not manufacture a vault deployment calldata blob. The server re-reads asset-manager authority, asset policy, registry provenance, and freshness before returning a single contract-deployment intent.

const prepared = await walletTorq.workflows.prepare({
  workflowType: 'role.asset_manager.vaultDeploy',
  chainId: 11155111,
  deploymentNamespace: 'sepolia',
  input: {
    assetAddress,
    assetManagerEntityId,
    ownerAddress,
    curatorAddress,
    allocatorAddress,
    protocolGuardianAddress,
    protocolFeeCollectorAddress,
  },
});

const completed = await walletTorq.workflows.execute(prepared, customerSigner);
if (completed.status !== 'final_success') throw new Error('Vault deployment was not canonically completed.');

tranchingEnabled and fee configuration are deliberately rejected at deployment. Configure them only through their separate, post-visibility owner workflows.

Earn deposits, redemption, and borrowing

Prepare deposit or borrow from the current canonical vault or market row, simulate the exact intent, submit through the customer-owned signer, register the hash, and wait for the response to reach final_success. A mined receipt, an RPC balance, or a locally estimated share amount is not the completion check.

The few-line Earn quickstart includes wallet authentication, the complete product catalogue, reviewed deposits, redemption, and position-through-recovery reads. Borrowing and other credit-business workflows remain explicit typed methods on earn.client because their authority and business inputs differ by role and market. Use typed workflows for the full lifecycle and blocked-state behavior.

Create a market is not a public Developer Platform workflow

The current public workflow union has no marketDeploy or createSharedMarket type. Shared-market creation is intentionally not a public Developer Platform capability. Do not call a contract factory directly or use an internal UI operation as an integration API. Teams that need a market added to a sandbox should use their approved Torq preview process; this documentation will name a public workflow only after its role, authority, and canonical-finality proof exist.

Subscribe to events

Use POST /v1/stream-token with the relevant server-side application secret, subscribe with the returned short-lived token, persist the latest cursor after durable handling, and resume from that cursor after reconnect. For server-side delivery, create a webhook endpoint, verify the raw body, and deduplicate both event and delivery IDs. See Webhooks & Events.

What not to automate

Do not infer production access from a package name, API hostname, ABI, or Sepolia deployment. Do not retry a changed mutation body with the same idempotency key. Do not mark a transaction complete when it is merely mined; wait for canonical completion.

On this page