What do I send?
At minimum: symbol, side, price, and useful volatility context such as ATR. Do not send broker credentials. The agent key binds the request to your account.
Your trading bot should not be a black box. Titan shows what came in, what passed, what failed, and what the receipt actually proves before broker submission.
Titan diagnoses signals. Titan does not generate, route, or execute trades. Or check a past trade-history CSV ↓
POST /api/public/v1/eval?eval_mode=full is the front door. Send Titan the same kind of payload your bot would send toward a broker, read allow, then open the trace or decision receipt when a trace_id comes back.
curl -X POST https://www.titandiagnostics.io/api/public/v1/eval?eval_mode=full \ -H "X-Titan-Agent-Key: tak_..." \ -H "Content-Type: application/json" \ -d '{ "symbol": "NVDA", "side": "BUY", "close": 875.50, "atr": 14.2, "strategy_hint": "breakout_v2" }'
{
"ok": true,
"allow": true,
"reason_label": "Signal passed Titan's decision gates",
"trace_id": "3f1df0f05e2843708dcafeba67bcee6e",
"decision_summary_url": "https://.../analytics/autopsy/3f1d...",
"trace_viewer_url": "https://.../traces/3f1d...",
"next_action_hint": "your_bot_may_proceed"
}
At minimum: symbol, side, price, and useful volatility context such as ATR. Do not send broker credentials. The agent key binds the request to your account.
Configured gates for duplicate or stale signals, malformed order intent, market/session issues, cooldowns, exposure, sizing, brackets, account state, and broker-rejection patterns when state is available.
allow: true means Titan did not find a Titan-side blocker for that signal. It does not mean a broker accepted it or that a trade was placed. allow: false means do not trade; read the reason and next-action hint.
The response includes a trace_id plus trace/autopsy URLs when available. The receipt explains the input signal, gate status, reason label, proof boundary, and what Titan did not do.
Enter an order the way your bot would send it. Titan walks it through 26 pre-trade checks in order and stops at the first one that fails — then prints the slip. This one runs in your browser against a simulated flat account: nothing is sent, nothing is stored. For an API-backed simulated check with gate-by-gate output, run a sample eval →.
The strategy creates order intent. Titan evaluates it before broker submission, returns a decision summary with a trace id, and leaves execution to your own forwarder.
Your bot generates a proposed order and sends that order intent to Titan first.
Titan evaluates the signal against configured diagnostic checks before it can reach the broker.
Titan returns allow or block output with a reason, trace id, and decision receipt.
Titan's code contains no order-submission call — a static test fails the build if one appears. Your forwarder, on your machine, is the only thing that talks to your broker.
Plain answers for people comparing pre-trade checks, bot diagnostics, and decision receipts. The full version is on the FAQ page.
Titan Fortress is a hosted diagnostic layer for trading bots. A bot sends proposed order intent to Titan before broker submission. Titan evaluates configured checks, returns an allow or block answer, and records a decision receipt that explains what was checked. It is diagnostics and control infrastructure, not a broker or signal generator.
Titan makes trading bots inspectable by putting diagnostic checks before execution. It can surface duplicate webhooks, stale signals, malformed order intent, cooldown violations, daily-loss breaches, exposure limits, margin/PDT issues, and broker-rejection patterns before your forwarder submits an order. The benefit is clarity and traceability, not a profit claim or loss-prevention guarantee.
Titan is for people building retail trading bots, plus small desks that already have a strategy and execution path. It fits bots that send TradingView alerts, Python signals, or REST requests and need a checkpoint before broker submission. It is not for discretionary trading tips.
No. Hosted Titan evaluates and records signals; it does not independently place, close, or cancel broker orders. If Titan returns an allow result, your own forwarder or execution code decides what to do next. Your broker remains the system of record for orders, positions, and custody.
Titan's public examples are written around Alpaca because the hosted forwarder and CSV diagnostic support Alpaca workflows today. The core pre-trade eval API accepts generic order intent, but broker execution remains in your forwarder. If your broker differs, check the API shape and forwarder boundary before relying on it.
A pre-trade risk check evaluates an order before it reaches the broker. It can inspect side, symbol, market hours, cooldowns, daily loss, exposure, sizing, bracket validity, and account state. The check answers whether the order should continue, stop, or be reviewed before execution.
A decision receipt is the record Titan writes for a signal evaluation. It includes the signal, outcome, reason, trace details, and verification path when proof artifacts are available. A receipt proves what Titan recorded; it does not prove broker execution, fills, profitability, or strategy quality.
Inspect the request flow, decision receipt, broker boundary, API shape, and limits.
Your strategy sends BUY or EXIT intent to Titan. Titan checks it. Your forwarder sends only allowed orders.
The receipt shows the signal, result, reason, time, and verification path. It explains why the signal passed or stopped.
Public evals do not require broker credentials. Titan uses the agent key for account binding and keeps broker submission outside hosted Titan.
Use an agent key. Titan returns allow or block. It does not trade.
curl -X POST https://www.titandiagnostics.io/api/public/v1/eval?eval_mode=full \ -H "X-Titan-Agent-Key: tak_..." \ -H "Content-Type: application/json" \ -d '{ "symbol": "AAPL", "side": "BUY", "close": 227.18, "atr": 3.4 }'
{
"ok": true,
"allow": true,
"status": "SUCCESS",
"eval_mode": "full",
"coverage_scope": "full_pretrade",
"limited_coverage": false,
"reason_code": "WOULD_SUBMIT_ORDER",
"reason_label": "Signal passed Titan's decision gates",
"trace_id": "3f1df0f05e2843708dcafeba67bcee6e",
"next_action_hint": "your_bot_may_proceed"
}
A blocked signal returns "allow": false with the gate name in reason_label. Fetch the full verifiable receipt from /api/public/v1/decisions/{trace_id}. Full walkthrough: the 5-minute quickstart.
A gate cannot make a bad strategy good. Titan enforces your rules and records what happened — nothing more.
Titan does not predict or improve profitability, market fit, or trading performance.
Titan does not create signals. It evaluates the signal your strategy sends.
A Bitcoin anchor proves a record was committed at a known time, not that execution happened.
Titan does not hold funds. Public evals do not need broker credentials, and execution remains with your forwarder.
They show what Titan checked and decided — not that the decision was right or the trade made money.
Titan is built for practical automation failures, not market predictions. It helps explain what the bot actually sent before the mistake turns into a broker mystery.
TradingView can send the same alert more than once. Titan records the duplicate check before broker submission, so you can see what stopped and why.
Many operators now use AI to generate Alpaca or TradingView bot code. Those bots can miss required fields, side aliases, sizing, brackets, and stale state. Titan gives you a place to inspect the payload before it reaches a broker.
A signal can arrive after the market context changed. Titan shows the signal time and whether freshness or session checks affected the decision.
Your broker can still reject an order after Titan passes it. Titan does not guarantee broker approval; it shows Titan-side blockers and likely failure causes before submission.
Use Deploy Gate before changing settings you rely on. It compares the change against past Titan receipts so you can see what would flip.
A trace shows the submitted signal, normalized intent, gate path, and reason label. The receipt proves Titan's diagnostic decision, not execution, fills, or P/L.
Beta stays free while we onboard early operators. The pricing test is intentionally simple: one active bot/operator, full evals, receipts, and trace history.
Create an agent key, run full evals, inspect decision receipts, and review trace history while beta access is open.
Create accountLikely starter tier after beta: one active bot/operator, full evals, decision receipts, trace history, and broker-rejection diagnostics. Final packaging may change.
Create accountUpload Alpaca trade history. Titan replays the file through default gates and shows what would have stopped. No account needed.
Processed for this check. Not stored.