> For the complete documentation index, see [llms.txt](https://titan-exchange.gitbook.io/titan/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://titan-exchange.gitbook.io/titan/developer-doc/special-order-types/overview.md). # Overview Server-to-server DCA, stop-loss, take-profit, OCO and Slice 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. Five order types run on one integration: | `orderType` | What it does | | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | [`dca`](/titan/developer-doc/special-order-types/order-types/dca.md) | Spends a fixed amount on a schedule until the total runs out | | [`stop_loss`](/titan/developer-doc/special-order-types/order-types/stop-loss-take-profit.md) | Sells the full deposit when the price falls to a trigger | | [`take_profit`](/titan/developer-doc/special-order-types/order-types/stop-loss-take-profit.md) | Sells the full deposit when the price rises to a trigger | | [`oco`](/titan/developer-doc/special-order-types/order-types/oco.md) | One deposit, a floor and a ceiling — the first fill cancels the other | | [`slice`](/titan/developer-doc/special-order-types/order-types/slice.md) | Swaps one deposit as a sequence of smaller back-to-back swaps to reduce price impact | A stop-loss, take-profit or Slice Order can also arm a [take-profit / stop-loss bracket](/titan/developer-doc/special-order-types/order-types/otoco.md) automatically on the tokens it buys. 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, trigger fills and slices), 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 a price (the pair ratio, or the input token's USD price, per `priceBasis`) and swaps its full deposit when a trigger is crossed. Created on the same endpoints as DCA. | | **Slice Order** | One deposit swapped as back-to-back smaller swaps, each quoted only after the previous one confirms, to reduce price impact. | | **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](/titan/developer-doc/special-order-types/quickstart.md) takes you from onboarding a user to creating your first order. [Order Types](/titan/developer-doc/special-order-types/order-types.md) covers what each type does and the `config` it takes. The [Guides](/titan/developer-doc/special-order-types/guides.md) cover the parts every type shares — [Onboarding](/titan/developer-doc/special-order-types/guides/onboarding.md), [Creating Orders](/titan/developer-doc/special-order-types/guides/creating-orders.md), [Managing Orders](/titan/developer-doc/special-order-types/guides/managing-orders.md), [Withdrawals](/titan/developer-doc/special-order-types/guides/withdrawals.md), [Platform Fees](/titan/developer-doc/special-order-types/guides/platform-fees.md), and [Lifecycle & Polling](/titan/developer-doc/special-order-types/guides/lifecycle.md). For the precise contract, see [Authentication](/titan/developer-doc/special-order-types/reference/authentication.md) and the full [Endpoints](/titan/developer-doc/special-order-types/reference/endpoints.md) reference.