Overview

Server-to-server DCA, stop-loss, take-profit, and OCO orders on Solana, built on Titan-managed wallets.

Titan lets you offer scheduled and price-triggered orders on Solana without holding user keys, running a price watcher, or building swap infrastructure. Your backend calls Titan; Titan provisions a managed wallet per user, executes each order when it's due, and returns swap output to the user's own wallet.

Four order types run on one integration:

orderType	What it does
dca	Spends a fixed amount on a schedule until the total runs out
stop_loss	Sells the full deposit when the price falls to a trigger
take_profit	Sells the full deposit when the price rises to a trigger
oco	One deposit, a floor and a ceiling — the first fill cancels the other

They share the same API key, the same user onboarding, the same two-step transaction flow, and the same endpoints. If you have DCA running, adding stop-loss is a new config shape — not a new integration.

The integration is server-to-server. There's no SDK in your frontend and no new login UI. Your users keep authenticating however they already do; your backend authenticates to Titan with one API key and identifies each user by the same stable id you already use for them.

How the pieces fit

Your backend holds a partner API key (X-Titan-Key) and sends it on every request. For anything user-specific, it also sends X-Titan-User — your own id for that user. Titan validates the key, attributes the request to your tenant, resolves the user, and executes the order on a Titan-managed Solana wallet that belongs to that user.

your backend ──(X-Titan-Key + X-Titan-User)──▶  Titan  ──▶  user's manager (policy-bound)
       │
       └─ once per user: POST /partner/onboard  (X-Titan-Key + user's SIWS)  ──▶  provisions the manager

The only cryptographic proof in the whole flow is a one-time Sign-In-with-Solana (SIWS) signature the user makes at onboarding. There's no OAuth, no token exchange, and no partner JWT.

Core concepts

Concept	What it means for you
Tenant	Your partner account inside Titan. Every order, execution, and row is tagged with your tenant id, so your data is isolated from other partners.
Partner API key (X-Titan-Key)	A server-side secret Titan issues you. Send it on every request. Never ship it to a browser.
Partner user id (X-Titan-User)	Your own stable id for an end-user. You supply it as sub at onboarding and as X-Titan-User on every user-scoped call. It's namespaced to your tenant, so two partners can use the same id without collision.
Manager	A Solana wallet created and managed by Titan but owned by the user. Titan signs only what the user's policy permits — order-execution swaps (DCA cycles and trigger fills), and withdrawals back to the user's own external wallet.
External wallet (userPubkey)	The user's existing Solana wallet. It pays network fees on user-signed transactions and, by default, receives swap output. The user proves ownership of it once, at onboarding, via SIWS.
Two-step transactions	Anything that changes on-chain state happens in two calls: intent (Titan returns an unsigned tx) → user signs → confirm (you send the signed tx back; Titan co-signs and broadcasts).
Trigger order	A one-shot order — stop_loss, take_profit, or oco — that watches the pair's price and swaps its full deposit when a trigger is crossed. Created on the same endpoints as DCA.
Automatic input return	When an order permanently fails — or a trigger order expires — Titan returns its remaining unspent input to the user's external wallet, with no partner action and no user signature. Funds reserved for the user's other active orders are left untouched.

Managers are global per end-user. If the same user shows up at another integrator with the same external wallet, they land in the same Titan-managed manager — balances and active orders follow the user.

Environments

Environment	Base URL	Notes
Production	https://api.chronos.titan.exchange/api/v1	Issued at onboarding.

A separate development base URL is provided at onboarding for end-to-end testing before launch. A key is bound to exactly one environment. Every endpoint path in this section is relative to the base URL.

Where to go next

The Quickstart takes you from onboarding a user to creating your first order. Order Types covers what each type does and the config it takes. The Guides cover the parts every type shares — Onboarding, Creating Orders, Managing Orders, Withdrawals, Platform Fees, and Lifecycle & Polling. For the precise contract, see Authentication and the full Endpoints reference.