Torque SDK
Inspect the package before you integrate.
Source and releases
Read the source on GitHub and its releases before choosing a version. It is MIT-licensed with an explicit public API.
Install and verify
Install @global-torque/sdk, pin the version and run its documented checks. Installation does not provision a Global Torque service; confirm target authentication and API revision separately.
Support and security
Report defects in GitHub issues and vulnerabilities through the private security route. Keep request IDs and typed failures for support; the host owns URLs, credentials and deployment policy.
Give your team control of the application layer.
Investor-facing experiences
Create a branded opportunity and portfolio experience around contracted resources. Own the information architecture, clear loading, empty and failure states, and identity/session integration.
Operations applications
Build focused screens to review applications, monitor provider outcomes and investigate exceptions. Show authorized records and actions, keep provider references and request IDs, and make retry and recovery explicit.
A foundation for integration
Put the SDK behind an app-owned resource and ViewModel. Configure origins at runtime, validate network data before UI models, and change the interface without rewriting transport.
A focused set of transport and resource capabilities.
Framework-free transport
Set service origins, authentication and lifecycle from the host. The SDK owns neither environment variables, routes, state nor UI; it supports cookie, bearer and typed Authorization strategies, scopes origins and credentials to each service, and disposes with the application lifecycle.
Validated resources
Supported resource subpaths cover offers, investments, profiles, forms, fund-manager and related service contracts. Responses remain unknown until validated; reject missing fields, wrong scalar types and malformed financial values, and check the deployment resource revision.
Bounded failures and safe reads
Typed HTTP, auth, authorization, validation, rate-limit, timeout, network and abort errors provide diagnostic context without putting response bodies in error messages. Safe GET, HEAD and OPTIONS requests use bounded backoff and jitter; idempotency keys are explicit and mutations are not retried automatically. The host handles reconciliation and recovery.
Optional wallet building blocks
Separate wallet subpaths provide injected EIP-7702, Turnkey and sponsored-call building blocks without provider dependencies in transport consumers. Validate delegate, sender, chain, target and call policy; resume pending calls and require a host-owned postcondition. Identity, eligibility and recovery UI stay in the app.
See a concrete starting point
The public Vue developer starter shows a read-only offer explorer and a small application surface. It clarifies the boundary between UI, host state and SDK data. It uses fictional fixtures, with no live service or investment transaction.
The screenshot is a real starter build. The visible offers, profiles and values are fictional demonstration data.
Read the developer starter source and the SDK integration guide to replace fixtures with an approved service contract. Live verification still requires a provisioned sandbox and application access.
Choose the amount of control your team needs.
| Starting point | What you adopt | What your team owns |
|---|---|---|
The White Label guide covers supplied branded experiences and established workflows. The Custom Components guide covers optional Vue primitives and compositions that can sit alongside the framework-free SDK.
Move from package inspection to a verified integration.
- Inspect and pin. Read the README, changelog and exports. Pin a release; list required resources and operations, then record owner, API revision, endpoint scope, authentication, CORS, timeout, rate-limit and idempotency contracts.
- Configure access. Agree HTTPS origins, user auth and any restricted app key before browser tests. Treat browser keys as public config, keep server secrets out of browser code, and verify the provisioned sandbox.
- Build and verify. Put calls in an app-owned resource; validate responses, map models in a ViewModel, and test loading, empty, failure, retry and reset states. Use starter fixtures first; retain request IDs and typed failures for support.
The integration boundary
The SDK supplies transport and validated resources; the host supplies routes, state, identity and user-facing decisions. Optional Vue packages are separate dependencies, not an umbrella SDK suite.
Read the full integration guide for transport and ViewModel examples.
Keep ownership clear across the integration.
What Torque SDK owns
The SDK owns transport, authentication strategies, bounded safe reads, typed errors, response validation and selected wallets, including request construction, parsing, correlation metadata, lifecycle disposal and credential isolation.
What your application owns
The app owns user flow and responses to waiting, unavailable or review-needed results. Routes, navigation, sessions, UI state, models, permissions, recovery, provider configuration, policy and deployment stay in the host.
What services and providers own
Global Torque services and connected providers own their operations, authorization and outcomes. Payment, custody, identity and registry confirmations come from those systems; each workflow defines completion evidence.
Common questions
Plan your first SDK integration.
