Order Types

The five order types you can create, the conditional-entry option, and how to pick between them.

Every order type runs on the same integration — same API key, same onboarding, same two-step transaction flow, same endpoints. Only orderType and the config object change. If you have DCA working, adding stop-loss is a new config shape, not a new integration.

What's available

orderType	Shape	Fires
dca	Recurring — spends amountPerCycle on a fixed schedule until totalAmount runs out	On a clock, every cycleFrequencySeconds
stop_loss	One-shot — sells the whole deposit	When the watched price falls to triggerPrice
take_profit	One-shot — sells the whole deposit	When the watched price rises to triggerPrice
oco	One-shot, one deposit, two triggers — the first leg to fire cancels the other	At either takeProfitPrice or stopLossPrice
slice	One deposit swapped as executions back-to-back smaller swaps, each quoted after the previous one confirms	Immediately after confirm, slice by slice

Stop-loss, take-profit and OCO are collectively trigger orders: they deposit their full amount up front, watch a price — the pair ratio or the input token's USD price, per priceBasis — and swap exactly once. Any of the three can be made trailing with trailingStopBps, so the trigger follows the market instead of sitting at a fixed level.

A stop_loss, take_profit or slice order can also carry onFillOco: when it fills, Titan automatically creates a take-profit / stop-loss bracket on the tokens it bought.

Choosing between them

User intent	Order type
Average into or out of a position over time, with no specific price	dca
A single exit at one price	stop_loss or take_profit
A floor and a ceiling on one position, with one deposit	oco
Protect gains without capping them	stop_loss or take_profit with trailing
Swap a large size now with less price impact	slice
Buy on a condition, then bracket the position automatically	stop_loss, take_profit or slice with onFillOco

What differs per type

Everything below is identical across all types, so build it once: authentication, onboarding (including onboardIfNeeded and its 409 fallback), the intent → sign → confirm pattern, the response envelope, balances, withdrawals, idempotency, and platform fees.

These are the real differences:

	dca	Trigger orders	slice
Status after confirm	active — or pending when config.startAt is in the future	active, always	active, then executing for the whole run
Executions	One row per cycle	Exactly one row, when it fires	One slice_fill row per confirmed slice
Modify	PATCH /dca/{orderId}	Parameter-only PATCH per type — Modify a trigger order	Not supported
Pause, resume, cancel	Supported	Supported	Not supported
Retry a failed order	Supported, in a brief window	Not supported (400 RETRY_NOT_SUPPORTED)	Not supported (400 RETRY_NOT_SUPPORTED)
expired orders	Withdraw manually	Deposit auto-returned	No expiry
Minimum notional	Applies to amountPerCycle	Applies to the full amount	Applies per slice (amount / executions)
Concurrency	Unlimited	Unlimited	One active / executing per user
Detail endpoint	GET /dca/{orderId}	GET /stop-loss/{orderId} · /take-profit/{orderId} · /oco/{orderId}	GET /slice/{orderId}

The per-type detail endpoints return 404 NOT_FOUND when the id exists but is a different orderType. Route off the orderType field from GET /me/orders rather than probing endpoints until one answers.

Related pages

• Creating Orders — the two-step flow every type shares

• Managing Orders — modify, pause, resume, cancel, retry

• Endpoints — the full route contract