API Reference

List the strategy templates available to launch. Each one is mechanical and documents its own worst case — nothing here is "AI-optimized" or opaque.

Example

curl https://api-helm.andestechsynergy.com/v1/templates

Response

[
  {
    "id": "demo-dca",
    "name": "Demo DCA",
    "description": "Buys a fixed dollar amount of an asset on a fixed interval...",
    "worstCase": "If the asset trends down for the whole run...",
    "settings": [],
    "trackRecord": { "checks": 240, "caught": 3, "agents": 6 }
  },
  {
    "id": "price-triggers",
    "name": "Price triggers",
    "description": "Buys when the price drops below a level you set, and closes when it rises above another...",
    "worstCase": "Both levels are fixed numbers you chose, and the market does not know about them...",
    "settings": [
      {
        "key": "buyBelow",
        "label": "Buy below",
        "help": "Opens a position each interval while the price is under this. Leave at 0 to never buy.",
        "default": 0, "min": 0, "max": 10000000, "step": 0.01, "unit": "USD"
      }
    ],
    "trackRecord": null
  }
]

settings are the numbers a template lets the caller choose, described well enough to build an input for without knowing anything about the strategy. The rule itself is never a parameter — that is what keeps worstCase true for every agent running the template. A template with no settings returns an empty array.

trackRecord is how the template has actually behaved: checked actions, distinct agents that ran it, and how many actions the policy engine stopped. It is null until at least 20 checks are behind it — a handful of runs is not a track record, and publishing one invites a reader to conclude more than the data supports. It describes what happened, and is not a prediction or a recommendation.

Launch a template as a running agent. Runs immediately, then again every intervalMs until stopped. Rate-limited to 10 requests/minute per IP.

Example

curl -X POST https://api-helm.andestechsynergy.com/v1/launch \
  -H "Content-Type: application/json" \
  -d '{
    "agentId": "my-first-agent",
    "templateId": "demo-dca",
    "chain": "ethereum",
    "protocol": "uniswap-v3",
    "asset": "ETHUSDT",
    "amountUsd": 100,
    "limits": { "maxLeverage": 1 }
  }'

Response

{ "agentId": "my-first-agent", "templateId": "demo-dca", "intervalMs": 15000 }

409 if that agentId is already running. 404 if templateId is unknown. 403 if the agentId is claimed and no matching X-Agent-Secret is presented. The response carries agentSecret only on the call that claims the id.

Move the account's own spot funds into its futures wallet. Aster keeps the two separate and a futures order can only draw margin from the futures side, so a funded account that has never done this cannot place an order — it fails with Margin is insufficient. Requires the agent's X-Agent-Secret.

Example

curl -X POST https://api-helm.andestechsynergy.com/v1/agents/my-first-agent/transfer   -H "Content-Type: application/json"   -H "X-Agent-Secret: ..."   -d '{ "amount": 100 }'

This is not a trade and is not evaluated by the policy engine: the engine decides whether an action may reach the market, and this one never does. It cannot move funds out of the account either — agents are approved with canWithdraw=false, and the transfer names both ends as the same user's wallets. 409 if the agent has no exchange account behind it (the stub venue, or nothing running under that id). 400 for a non-positive amount, or with the exchange's own refusal when it declines.

It exists so the agent key never has to be used off the AndesHelm server. That was previously a command a user ran locally with the key in hand, which is what stopped an approval being pinned to an ipWhitelist — a control that, per Aster, restricts every request signed by an agent wallet rather than only withdrawals.

Stop a running or paused agent and discard its venue credentials. Requires the agent's X-Agent-Secret.

To halt an agent without giving up its credentials, use POST /v1/agents/:agentId/pause and POST /v1/agents/:agentId/resume instead. A paused agent keeps its run index, so resuming continues a ramping or tapering strategy rather than restarting it, and does not ask for the agent wallet key again. Resume returns 409 for an agent that was stopped — stopping discards the credentials, so there is nothing to resume into.

curl -X POST https://api-helm.andestechsynergy.com/v1/agents/my-first-agent/stop   -H "X-Agent-Secret: $AGENT_SECRET"

{ "stopped": true }

403 without a matching secret, and also for an agentId nobody has claimed — otherwise stopping an unclaimed agent would be a way to claim it.

Live status: whether it's running, its launch params, current verification badge, and its recent checked actions with each policy decision and reasons. Requires the agent's X-Agent-Secret — this carries spend and leverage, so unlike the badge it is not public.

curl https://api-helm.andestechsynergy.com/v1/agents/my-first-agent/log   -H "X-Agent-Secret: $AGENT_SECRET"

{
  "running": true,
  "paused": false,
  "serviceStartedAt": 1788000000000,
  "launched": { "agentId": "my-first-agent", "templateId": "demo-dca", "intervalMs": 15000, "launchedAt": 1788000000000, "venueName": "aster-testnet" },
  "badge": { "verified": false, "checksRecorded": 3, "reason": "needs 7 more...", "stale": false },
  "log": [
    {
      "timestamp": 1788000000000,
      "result": {
        "executed": true,
        "evaluation": { "decision": "ALLOW", "reasons": ["within all configured policy limits"] },
        "venueResult": { "executed": true, "notes": ["stub execution..."] }
      }
    },
    {
      "timestamp": 1788000015000,
      "result": null,
      "error": "fetch failed"
    }
  ]
}

serviceStartedAt is when the API process last started, and is returned by /v1/launch too. Launched agents are held in memory, so a restart — a deploy, or the host recycling an idle process — stops all of them, and credentials are deliberately not persisted so they cannot be resumed. Compare this value against the one you saw at launch: if it changed, your agent was stopped by a restart rather than by anything it did. Verification track records are persisted and survive. Compare it to itself rather than to your own clock, which may not agree with the server's.

result is null when a run failed before the policy engine returned a decision — the agent could not reach it, or the venue call threw. The error field is present only on those entries. A failed run executes nothing and is not recorded against the agent's verification track record; the agent keeps running and retries on the next interval. Failures are reported rather than hidden, so an agent that stopped being checked never looks like one whose checks all passed.

Verification status as JSON: whether the agent has enough consecutive clean checks to be considered verified, and whether that track record has gone stale (no checked action in 30+ days).

curl https://api-helm.andestechsynergy.com/v1/badge/my-first-agent

{ "verified": true, "checksRecorded": 11, "reason": "11 consecutive checked actions with no BLOCK", "stale": false }

The same status as an embeddable image — drop it in a README or a listing page. Self-contained SVG, no external fonts.

<img src="https://api-helm.andestechsynergy.com/v1/badge/my-first-agent/svg">

Verified agents only, sorted by check count — unverified one-off test runs stay private by default. This is what powers the public directory page.

curl https://api-helm.andestechsynergy.com/v1/directory

[
  { "agentId": "my-first-agent", "badge": { "verified": true, "checksRecorded": 11, "reason": "...", "stale": false } }
]