Docs

Build securely with Torq and AI

Ground an AI system in Torq, create institutional earn copilots, and prepare non-custodial workflows without giving a model signing authority.

Developer Preview. These docs and machine-readable sources are public. Credentials, SDK distribution, approved-role access, sandbox admission, and production access remain controlled.

Give an AI verified Torq context

Torq publishes a compact context pack, a full developer index, the governed OpenAPI contract, and the capability catalogue. Use them together so an AI can answer from current sources instead of guessing how tokenized credit works.

GoalStart here
Give ChatGPT, Claude, or another assistant Torq contextAI quickstart
Build a retrieval pipeline over all developer documentationRetrieval and grounding
Build an earn discovery and portfolio copilotBuild an earn agent
Let an AI prepare, but never sign, a transactionSecure workflow execution
Test hallucination, freshness, tenant, and signer boundariesEvaluate your AI
Download canonical machine-readable sourcesMachine-readable reference

The safe agent boundary

An AI may read canonical Postgres/API state, explain risk and liquidity, compare eligible products, recommend an action, and ask Torq to prepare a typed workflow. A customer-controlled signer must still inspect, authorize, sign, and submit every value-moving transaction.

Question
  -> retrieve Torq sources
  -> read current API state
  -> explain evidence and limitations
  -> propose an action
  -> obtain explicit user approval
  -> prepare a typed Torq workflow
  -> customer-controlled signer validates and signs
  -> register transaction
  -> wait for canonical final_success

The model never receives private keys, seed phrases, reusable wallet proofs, or unrestricted calldata. It never treats an RPC receipt as product completion and never invents a contract target.

Earn experiences you can build

  • Wallets, neobanks, and exchanges: explain institutional earn products, eligibility, yield, liquidity, allocations, positions, and redemption state inside an existing customer experience.
  • Asset managers and financial service providers: help teams assemble and monitor governed earn programs while keeping approvals and signing outside the model.
  • Yield aggregators: compare eligible Torq vaults, disclose partner economics, and route users through approved wrappers while preserving fee and canonical-state truth.

One source hierarchy

When sources disagree, use this order:

  1. OpenAPI contract for methods, paths, auth, requests, and responses.
  2. Capability catalogue for availability and access class.
  3. Canonical API responses for current product-visible state.
  4. Developer index and guides for concepts and implementation guidance.

Fail closed on missing sources, stale freshness evidence, unknown enum values, or capability_not_ready.

On this page