API Reference

Liveness. Poll this from a watchdog.

Tiny and unauthenticated on purpose: a watchdog that needs a credential stops working the day the credential expires.

Response

{
  "ok": true,
  "uptime_s": 37821,
  "started": 1788913578
}

The five markets and everything that differs between them.

Labels, size units, cost model, leverage limits, whether the market can be shorted, and the direction words it uses (futures LONG/SHORT, everything else BUY/SELL).

Response

{
  "ok": true,
  "markets": {
    "futures": {
      "label": "FUTURES",
      "side_labels": {
        "long": "LONG",
        "short": "SHORT"
      }
    }
  }
}

The ten strategies, with what each suits and fails at.

Response

{
  "strategies": [
    {
      "id": "confluence",
      "name": "Confluence, 5 rules"
    }
  ]
}

The full rule specification for one strategy.

The ticker strip used by the landing page.

Response

{
  "rows": [
    {
      "symbol": "BTCUSDT",
      "price": 79120.0,
      "pct": -0.55
    }
  ]
}

A whole board of prices at once.

Candles and the current quote for one symbol.

Ranges 15m to 5y. The 1s range is crypto only, and several ranges are Pro; a trial gets 403 with an `upgrade` field.

Order book depth. Crypto only.

Biggest 24-hour movers on Binance.

Find a symbol by name.

Headlines for a symbol, or the general feed.

Overnight Radar: how the reference markets moved since the Jakarta close, weighted into one bias figure.

The weights are hand-chosen, not fitted. The figure is indicative and the response says so.

The technical signal for one symbol, with the rules that fired and the levels derived from ATR.

A trial sees the signal and the rule breakdown but not the entry, stop and target levels. This is a calculation over rules, not a forecast, and it has not been backtested by itself - the response carries that disclaimer.

Response

{
  "ok": true,
  "side": "long",
  "label": "LONG",
  "score": 4,
  "levels": {
    "entry": 79120,
    "stop": 77900,
    "tp1": 80340
  }
}

Scan a whole board and return only what passes the threshold.

Replay the rules bar by bar over one symbol.

Signals are computed from bars 0..i and the position opens at the OPEN of bar i+1, so nothing acts on a price it could not have known. A bar that touches both stop and target counts as a stop.

The same, across a whole board.

Submit a result computed on the customer's own machine.

Backtests run on the customer's computer; only the result comes here. Plan limits are enforced on this endpoint, so a result outside the plan is refused after it was computed.

Request body

{
  "email": "you@example.com",
  "key": "NUSA-XXXX-XXXX-XXXX-XXXX",
  "result": {
    "symbol": "BTCUSDT",
    "trades": 262,
    "avg_r": -0.151
  }
}

Upload a JSON file of results saved offline.

Request body

{
  "results": [
    {
      "symbol": "BTCUSDT",
      "trades": 262
    }
  ]
}

Stored results. Add ?id= for one result in full.

Symbols worth testing next, from your own history.

What your stored backtests support, per market.

Deduplicated, never pooled across markets, and corrected for selection: a strategy is only 'supported' if it beats the plain EMA baseline by a margin. This is what the automation engine consults before it will arm.

Everything about one market's automation account.

Capital, risk, symbols, strategy, venue, open positions, the recent log, the evidence verdict, and whether the broker keys are stored and unlocked. Each market is a separate account.

Every automation action, chosen by the `act` field.

act: config, arm, venue, keys, unlock, forget, close, kill, plan, apply_plan, balance, sync_capital, add, remove. `arm` refuses when your own backtests show the chosen strategy losing in that market - that refusal is the point of the feature, not a fault.

Request body

{
  "act": "arm",
  "market": "futures",
  "on": true
}

An AI explanation of a signal or of a market's evidence.

The model is given figures this server already computed and asked to explain them. It is never asked what the market will do, and it cannot see prices. You choose a subject; you cannot send a prompt.

Create an account. Starts on the trial plan.

Request body

{
  "email": "you@example.com",
  "password": "at least 8 characters",
  "name": "Your Name"
}

Sign in. Sets the session cookie every other call needs.

Request body

{
  "email": "you@example.com",
  "password": "\u2026"
}

End the session.

Public because clearing a cookie that is not there is harmless, and refusing it would only make a signed-out client handle an error it cannot act on.

Ask for a password reset link.

The reply is identical whether or not the address is registered - telling the difference would let anyone test for customer addresses.

Request body

{
  "email": "you@example.com"
}

Set a new password with the emailed token.

Changing the password deletes the stored broker API keys: they are encrypted under the old one and cannot be reopened.

Request body

{
  "token": "\u2026",
  "password": "\u2026"
}

Account, plan, and trading performance per venue.

What this plan allows: quotas, markets, strategies.

Licence state for this session or device.

Team members who receive backtest results by email.

Request body

{
  "act": "add",
  "email": "colleague@example.com"
}

Plans for sale, the networks accepted, and your invoices.

Public: the plan catalogue and the receiving wallet address are already on the pricing page, and a wallet nobody can read is a wallet nobody can pay. The `invoices` array is scoped to the session, so an anonymous caller gets an empty one - your invoices are never visible to anyone else.

Response

{
  "ok": true,
  "plans": [
    {
      "id": "pro1y",
      "usd": 3000
    }
  ],
  "networks": [
    {
      "id": "tron",
      "label": "TRON (TRC20)"
    }
  ],
  "invoices": []
}

Create an invoice: an address and an amount.

Request body

{
  "plan": "pro1y",
  "network": "tron"
}

Submit the transaction id. Verified on-chain, then the plan activates.

The transaction is checked against the address the invoice named, not the address currently configured - so changing the receiving wallet never invalidates an invoice already issued.

Request body

{
  "id": 4,
  "txid": "\u2026"
}