Elfa AI

Elfa API Skill

This skill enables agents to work with the Elfa API — a social listening, market context layer, and automated condition engine for crypto. Elfa ingests real-time data from Twitter/X, Telegram, and other sources, then structures sentiment, narratives, and attention shifts into actionable trading insights. The Auto subsystem adds a managed condition engine and trigger pipeline — describe what to watch for, and Auto evaluates continuously and fires actions when conditions are met. The Trade subsystem adds direct, synchronous order execution — place and manage perp orders on Hyperliquid and GMX immediately, without a condition or query.

Full documentation: docs.elfa.ai

Staying current — check weekly. This skill is updated on a weekly cadence to track Elfa API and Auto changes. Before relying on it, check whether your copy may be stale: if it has been more than 7 days since this skill was last fetched/installed (or you are unsure), re-fetch the latest version before acting —

• Skill package & changelog: (and the elfa-ai/skills repo).
• Live source of truth: docs.elfa.ai — when this skill and the docs disagree, the docs win; prefer the docs and flag the mismatch to the user.

When in doubt about a specific endpoint, parameter, or price, verify against docs.elfa.ai at call time rather than trusting a possibly-stale copy.

Environment and credentials

Elfa supports API-key auth and x402 keyless payments. API keys are optional when using x402.

x402 wallet signing is handled client-side by @x402/fetch or @x402/axios.

When to use this skill

• User asks about trending tokens, narratives, or contract addresses in crypto
• User wants social mentions for a specific ticker or keyword
• User wants smart stats (smart followers, engagement) for a Twitter/X account
• User wants an AI-generated market summary, macro overview, or token analysis
• User asks how to integrate, call, or use the Elfa API
• User wants code examples (curl, Python, JavaScript/TypeScript) for Elfa endpoints
• User mentions "elfa" in a crypto or trading data context
• User wants to set up automated alerts or monitoring on price, indicators, or narratives
• User wants to build condition-based triggers (e.g., "alert me when BTC crosses 100k")
• User mentions Auto, EQL, condition engine, or trigger pipeline in a crypto context
• User wants agent workflows that react to market conditions automatically
• User wants to build queries with Builder Chat using natural language

API Overview

Base URL: https://api.elfa.ai Version: v2 (current) Docs: docs.elfa.ai

Two access modes

Elfa supports two independent ways to authenticate requests:

Both modes access the same data. The only difference is how you authenticate:

• API key — register at https://go.elfa.ai/claude-skills, get 1,000 free credits.
• x402 — pay per request with USDC on Base, Arbitrum, Polygon, or Avalanche. No registration, no API key. Currently in beta with a 70% discount on Auto endpoints.

Endpoints at a glance

Data endpoints

All endpoints below work with both /v2/ (API key) and /x402/v2/ (keyless) prefixes, except key-status which is API key mode only.

Auto endpoints (Condition Engine)

Auto endpoints are available under /v2/auto/ (API key, HMAC for trade/exchange routes) and /x402/v2/auto/ (keyless). See Auto docs for full details.

Auth column legend (tables below). API key = x-elfa-api-key only (no HMAC). Conditional = HMAC required only when the EQL action is trade-flavoured (market_order, limit_order, or llm callback to those); notification-only actions (notify, telegram_bot, webhook, llm callback to those) skip HMAC. HMAC = HMAC always required. See HMAC Bypass for Notification-Only Mutations.

API key mode (/v2/auto/*):

Query lifecycle:

Query drafts (editable, not yet active):

LLM sessions (for action.type: "llm" queries):

Executions (trigger fire records):

Exchange connections (for live trade actions):

Other:

x402 mode (/x402/v2/auto/*) — note: some routes use POST instead of GET:

Note on x402 Auto scope. Trade execution actions are not available via x402. Exchange connections, drafts, executions, and the terminal-query DELETE endpoint are API-key-mode only. x402 Auto covers the core monitoring lifecycle (chat, validate, create, poll, cancel, stream, sessions).

Trade endpoints (Direct Execution)

Trade is direct, synchronous order execution — one request, one order, no condition engine. Same x-elfa-api-key + HMAC auth and same venues (hyperliquid, gmx) as Auto; they differ only in when the order fires. Trade is API-key mode only (no x402). See Trade docs for full details.

All endpoints are POST under /v2/trade. HMAC is required on every write; previews are free and unsigned.

Credits & billing. 1 credit per executed order (place / close / tpsl), charged only on a 2xx; failed fills (422/502) are never billed. Previews, cancels, and modifies are free. Trade bypasses the monthly spend-cap hard-stop (a key over its limit still trades and bills overage).

For full parameter details, see the Elfa API documentation.

Machine-readable manifest: an endpoint manifest is published at https://docs.elfa.ai/assets/files/endpoints.manifest-*.json (path rotates per release) — each entry includes method/path, docs route, required headers, HMAC requirement with mounted signature path template, payment requirement, and request/response examples. Useful for auto-generating client code.

How to use this skill

Step 1: Determine the mode

Check whether the user wants to make a live call, get code/integration help, or set up automated monitoring.

• If the user says things like "show me trending tokens", "what's the sentiment on SOL", "get me the top mentions for ETH" → they want live data. Proceed to Step 2a.
• If the user says things like "how do I call the trending tokens endpoint", "give me a curl example", "help me integrate Elfa" → they want code snippets. Skip to Step 4.
• If the user mentions x402, keyless, pay-per-request, or wallet-based access → they want x402 mode. See Step 2b for live calls or Step 4 for code snippets.
• If the user mentions Auto, alerts, triggers, monitoring, conditions, "alert me when", "notify me if", EQL, or Builder Chat → they want Auto. Proceed to Step 3.

Step 2a: Making live API calls (API key mode)

Use the bash_tool to call the Elfa API via curl.

Getting the API key:

1. Check if the ELFA_API_KEY environment variable is set. This is the preferred method.

2. If the env var is not set, stop and prompt the user. Offer both options:

   To make live calls, you have two options:

   Option A — API key (free tier): Get a free key with 1,000 credits at https://go.elfa.ai/claude-skills — then set it as the ELFA_API_KEY environment variable (do not paste it directly into the chat).

   Option B — x402 keyless payments: Pay per request with USDC on Base, Arbitrum, Polygon, or Avalanche — no signup needed. See the x402 docs for setup.

   Do not attempt any authenticated API calls without a key or x402 setup. Wait for the user.

3. Credential safety:

   • Always read the API key from the ELFA_API_KEY environment variable, never ask the user to paste it into the conversation.
   • Never log or expose the full API key in outputs — mask it when displaying curl commands.
   • Never echo or print environment variables: Do not run echo $ELFA_API_KEY, env | grep ELFA, printenv, or similar commands that would expose credentials in the transcript.
   • If a user does paste a key in chat, warn them to rotate it and set it as an env var instead.

Free tier limitations: The free tier provides 1,000 credits that cover most endpoints (trending tokens, smart stats, top mentions, keyword mentions, event summary, token news, trending contract addresses). Some endpoints require a higher tier: trending narratives needs Grow or Enterprise, and AI chat needs Grow, Enterprise, or PAYG. The Chill tier adds more credits but no new endpoints over Free. Check https://go.elfa.ai/claude-skills for the latest tier requirements.

If a user hits an authorization error on one of these endpoints, let them know they can upgrade their plan or use x402 payments instead. Full details at https://go.elfa.ai/claude-skills.

Making the call:

curl -s -H "x-elfa-api-key: $ELFA_API_KEY" "https://api.elfa.ai/v2/aggregations/trending-tokens?timeWindow=24h&pageSize=10"

Step 2b: Making live API calls (x402 keyless mode)

x402 lets any wallet pay per request using USDC on Base, Arbitrum, Polygon, or Avalanche — no API key, no registration. This is ideal for agents, bots, and programmatic access.

How x402 works:

1. Send a request to the /x402/v2/ version of any endpoint (no auth header).
2. The server responds with HTTP 402 containing payment requirements.
3. Your wallet signs a USDC transfer authorization (no gas fees).
4. Resend the request with the signed payment in the PAYMENT-SIGNATURE header.
5. Server verifies payment, serves the response, and settles on-chain.

x402 signing and security:

• Signing happens entirely client-side using the @x402/fetch or @x402/axios libraries. The agent never handles, stores, or transmits private keys.
• The user's wallet private key is used only locally by the x402 library to sign EIP-712 typed data authorizing a specific USDC amount for a specific request.
• Never ask the user to share their wallet private key or seed phrase in the conversation.
• When generating x402 code examples, use "0xYOUR_PRIVATE_KEY" as a placeholder and advise the user to load it from an environment variable (e.g., process.env.PRIVATE_KEY).

x402 details:

• Networks: the server offers every supported network in the 402 response; your client signs on the first one it's registered for. Register the network(s) you hold USDC on.
• Scheme: exact (fixed price per request); asset is native Circle USDC (6 decimals).
• Status: Currently in beta.

x402 pricing (data endpoints):

Making an x402 call with curl (manual flow):

# Step 1: Send request without payment — get 402 with payment requirements
curl -s https://api.elfa.ai/x402/v2/aggregations/trending-tokens?timeWindow=24h

# Step 2: After signing the payment payload with your wallet, resend with payment header
curl -s -H "PAYMENT-SIGNATURE: " \
  "https://api.elfa.ai/x402/v2/aggregations/trending-tokens?timeWindow=24h"

Recommended: use the @x402/fetch library which handles payment automatically:

import { wrapFetchWithPayment } from "@x402/fetch";
import { ExactEvmScheme, toClientEvmSigner } from "@x402/evm";
import { x402Client } from "@x402/core/client";
import { createPublicClient, http } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { base } from "viem/chains";

const account = privateKeyToAccount("0xYOUR_PRIVATE_KEY");
const publicClient = createPublicClient({ chain: base, transport: http() });
const signer = toClientEvmSigner(account, publicClient);

const client = new x402Client().register(
  "eip155:8453",
  new ExactEvmScheme(signer));

const x402Fetch = wrapFetchWithPayment(fetch, client);

// Use x402Fetch exactly like regular fetch — payment is handled automatically on 402 responses
const response = await x402Fetch(
  "https://api.elfa.ai/x402/v2/aggregations/trending-tokens?timeWindow=24h");
const data = await response.json();

To pay on another network, swap the base chain import and register that scheme instead — e.g. Arbitrum (arbitrum from viem/chains, eip155:42161). Register a scheme for each network you want to pay from; the client uses the first one the server also accepts.

x402 with the Chat endpoint (POST):

const response = await x402Fetch(
  "https://api.elfa.ai/x402/v2/chat",
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      message: "What is the current sentiment on BTC?",
      analysisType: "chat",
      speed: "fast", // "fast" = 5 credits ($0.045), "expert" = 18 credits ($0.162)
    }),
  });
const data = await response.json();
console.log(data.data.message);

Presenting results:

• Parse the JSON response and present it in a clean, readable format.
• For trending tokens: show a ranked table with token name, mention count, and change %.
• For mentions: show tweet links, engagement metrics, and account info. Note: Elfa returns tweet IDs but not tweet text content — let the user know they'll need their own X (Twitter) API key to fetch the actual tweet content.
• For narratives/summaries: present the narrative text with source links.
• For the chat endpoint: display the AI response cleanly.
• If the response contains an error, explain what went wrong and suggest fixes.

Step 3: Auto — Condition Engine and Trigger Pipeline

Auto is a managed condition engine + trigger pipeline for agents. You describe what to watch for (price, technical indicators, LLM-evaluated conditions, scheduled checks, prediction-market activity, funding rates, liquidation cascades, market sentiment), and Auto evaluates continuously and fires actions when conditions resolve to true. Assets are not crypto-only — HIP-3 perps cover equities, indices, commodities, FX, and pre-IPO names, 24/7.

Full Auto docs: docs.elfa.ai/auto/overview

Lifecycle Sequence (Enforced)

For API key lifecycle/cleanup calls, preserve this order when each operation applies:

1. POST /v2/auto/queries/validate — validate EQL and preview cost
2. POST /v2/auto/queries — create and activate
3. POST /v2/auto/queries/{queryId}/cancel — only if stopping an active query before it reaches terminal status (returns 409 once terminal)
4. DELETE /v2/auto/queries/{queryId} — only after status is terminal (triggered / expired / cancelled / failed); active queries must be cancelled first

Cancel and delete are distinct operations. POST /cancel flips an active query to cancelled (terminal). DELETE removes the record entirely and only works on terminal queries. Sending DELETE on an active query returns 409 Conflict.

Important — Exchange preflight for trade actions: For trade actions (market_order, limit_order, or llm with a trade callback), always call GET /v2/auto/exchanges before creating the query to verify the target exchange is connected. Without an active exchange connection, query creation may succeed but the trade action fails at execution time with AGENT_WALLET_REQUIRED. If the exchange is not connected, inform the user they need to link it via the Elfa dashboard before the trade trigger can work.

x402 mode supports the same lifecycle except: x402 has no DELETE endpoint (cancel-only), and trade actions are not available via x402.

Intent Routing (Strict)

Pick the condition source by user intent before writing condition args:

When the prompt is account-anchored, start with tweet — do not route to news or llm first. When the prompt is event-anchored without a specific account, start with news. When the trigger maps to a concrete prediction market you can name (a Kalshi ticker or a Polymarket outcome-token id), use kalshi / polymarket (prefer them over llm for supported methods). Use llm (athena_condition) only when the predicate cannot reasonably be matched against a post, event, or named prediction market.

When to suggest Auto

• User wants alerts based on price thresholds ("alert me when BTC crosses 100k")
• User wants alerts based on technical indicators ("notify when RSI drops below 30")
• User wants scheduled checks ("check every 4 hours") or calendar schedules ("every weekday at 9am New York time" — use cron.schedule)
• User wants the same alert to keep firing on its own condition ("notify me every time BTC dips below 60k") — add the top-level repeat object (cooldown + maxTriggers)
• User wants narrative/sentiment monitoring ("alert when AI token narrative shifts")
• User wants multi-condition triggers ("BTC above 100k AND ETH above 3500")
• User wants to compare live metrics ("alert when price crosses above Bollinger Band")
• User wants LLM analysis on trigger ("when it triggers, run a full analysis")
• User wants account-anchored social triggers ("notify me when @cz_binance posts that Binance Alpha is listing a new token") — use Signal: X/Twitter Post (source: "tweet")
• User wants event-driven triggers ("alert me when SEC approves a spot ETH ETF") — use Signal: Event (source: "news")
• User wants prediction-market triggers ("alert when this Kalshi market's YES probability crosses 60%", "notify when the market settles YES", "alert when this Polymarket outcome trades above 60c") — use Prediction Markets (source: "kalshi" or source: "polymarket")
• User wants funding / liquidation / sentiment triggers ("alert when BTC funding flips negative", "notify on an ETH liquidation cascade", "alert when Fear & Greed drops below 20") — use source: "funding" / "liquidation" / "fear_greed"
• User wants to trade a macro catalyst on stocks/indices/commodities ("go long the S&P when the market prices a Fed cut", "buy gold if CPI runs hot") — fire on the catalyst source and execute on a HIP-3 perp (24/7). See Catalyst Triggers

Auto access models

HMAC signing (API key mode — trade mutations and exchange linking)

Trade-action mutations and exchange linking under /v2/auto/* require HMAC signing in addition to x-elfa-api-key. Notification-only mutations skip HMAC so agents can onboard without provisioning a secret — see HMAC Bypass for Notification-Only Mutations below for the per-route decision rule. Read-only endpoints (GET) only need the API key. POST /v2/auto/chat is fully ungated and never needs HMAC.

Always-signing remains safe. If your client signs every mutation, you do not need to opt into the bypass. Signed requests are accepted on every route. The bypass is purely an optimization for clients that want to skip the HMAC setup step.

Required headers for signed mutations:

x-elfa-api-key: 
x-elfa-timestamp: 
x-elfa-signature: 

Signing payload:

timestamp + method + mounted_path + body

CRITICAL: mounted_path is the path inside /v2/auto, NOT the full URL path.

• Request URL: /v2/auto/queries → signed path: /queries
• Request URL: /v2/auto/chat → signed path: /chat
• Request URL: /v2/auto/queries/q_123 → signed path: /queries/q_123

Replay protection: timestamp must be within 30 seconds.

TypeScript signing example:

import crypto from "crypto";

const hmacSecret = process.env.ELFA_HMAC_SECRET!;
const apiKey = process.env.ELFA_API_KEY!;

function signAutoRequest(method: string, mountedPath: string, body: string = "") {
  const timestamp = Math.floor(Date.now() / 1000).toString();
  const payload = `${timestamp}${method}${mountedPath}${body}`;
  const signature = crypto
    .createHmac("sha256", hmacSecret)
    .update(payload)
    .digest("hex");
  return { timestamp, signature };
}

// Example: Create a query
const body = JSON.stringify({
  title: "BTC breakout alert",
  description: "Notify when BTC trades above 100k.",
  query: {
    conditions: {
      AND: [{ source: "price", method: "current", args: { symbol: "BTC", exchange: "hyperliquid" }, operator: ">", value: 100000 }]
    },
    actions: [{ stepId: "step_1", type: "notify", params: { message: "BTC crossed 100k" } }],
    expiresIn: "24h"
  }
});

const { timestamp, signature } = signAutoRequest("POST", "/queries", body);

const response = await fetch("https://api.elfa.ai/v2/auto/queries", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "x-elfa-api-key": apiKey,
    "x-elfa-timestamp": timestamp,
    "x-elfa-signature": signature,
  },
  body,
});

Bash signing example:

TIMESTAMP=$(date +%s)
METHOD="POST"
PATH_SIGN="/queries"
BODY='{"title":"BTC alert","query":{"conditions":{"AND":[{"source":"price","method":"current","args":{"symbol":"BTC","exchange":"hyperliquid"},"operator":">","value":100000}]},"actions":[{"stepId":"step_1","type":"notify","params":{"message":"BTC crossed 100k"}}],"expiresIn":"24h"}}'
SIGNATURE=$(echo -n "${TIMESTAMP}${METHOD}${PATH_SIGN}${BODY}" | openssl dgst -sha256 -hmac "$ELFA_HMAC_SECRET" | cut -d' ' -f2)

curl -s -X POST "https://api.elfa.ai/v2/auto/queries" \
  -H "Content-Type: application/json" \
  -H "x-elfa-api-key: $ELFA_API_KEY" \
  -H "x-elfa-timestamp: $TIMESTAMP" \
  -H "x-elfa-signature: $SIGNATURE" \
  -d "$BODY"

HMAC Bypass for Notification-Only Mutations

Mutations whose EQL action is a pure notification skip the HMAC requirement. Trade execution and exchange linking continue to require HMAC unconditionally.

Notification action types (HMAC bypassed):

• notify
• telegram_bot
• webhook
• llm whose params.callback.action.type is one of the above

Trade action types (HMAC required):

• market_order
• limit_order
• llm whose params.callback.action.type is market_order or limit_order

Decision is per-route:

If the lookup fails or the action type is unknown, HMAC is enforced (fail-safe). Unknown action types added in future API versions default to requiring HMAC, so always-signing clients keep working.

POST /v2/auto/chat is fully ungated regardless of content because it produces drafts only — activation flows through convert, which is still gated when the draft is trade-flavoured.

POST /v2/auto/exchanges and DELETE /v2/auto/exchanges/:exchange always require HMAC — linking an exchange is the gateway to trade execution.

Why this matters for agents. An agent that only ever sends notify / telegram_bot / webhook actions can call POST /v2/auto/queries, POST /v2/auto/queries/:id/cancel, DELETE /v2/auto/queries/:id, etc. with just x-elfa-api-key — no HMAC secret provisioning required. Agents that need trade execution must still configure ELFA_HMAC_SECRET for the trade-flavoured calls and for exchange linking.

x402 Auto (keyless agent mode)

For x402 Auto, no API key or HMAC is needed. Instead:

• Send x402 payment headers (PAYMENT-SIGNATURE preferred, X-PAYMENT legacy)
• Include x-elfa-agent-secret on all query lifecycle routes

Agent secret management: Generate a strong secret once and reuse it for all calls:

openssl rand -hex 32
# or: node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

Persist as ELFA_AGENT_SECRET. Do not rotate per request — x402 session ownership is derived from SHA256(secret). If you change secrets, your agent identity changes and existing queries/sessions may become inaccessible.

Auto pricing (both modes)

API-key mode (/v2/auto/*) — charged against your credit balance:

Reference USD values for Create: baseline $0.045, fast call +$0.045, expert call +$0.162. Use /queries/validate to preview exact cost before committing.

x402 mode (/x402/v2/auto/*) — 70% discount, limited-time, pay-per-request in USDC on Base, Arbitrum, Polygon, or Avalanche:

x402 Auto example:

// Validate a query (x402 Auto)
const response = await x402Fetch(
  "https://api.elfa.ai/x402/v2/auto/queries/validate",
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-elfa-agent-secret": process.env.ELFA_AGENT_SECRET,
    },
    body: JSON.stringify({
      query: {
        conditions: { AND: [{ source: "price", method: "current", args: { symbol: "BTC", exchange: "hyperliquid" }, operator: ">", value: 100000 }] },
        actions: [{ stepId: "step_1", type: "notify", params: { message: "BTC crossed 100k" } }],
        expiresIn: "24h"
      }
    }),
  });

Recommended call sequence (deterministic agent path)

API key mode (/v2/auto/*):

1. POST /v2/auto/chat — Ask Builder Chat to draft a query
2. POST /v2/auto/queries/validate — Validate EQL and preview cost
3. (Trade actions only) GET /v2/auto/exchanges — Confirm an active exchange connection
4. POST /v2/auto/queries — Create and activate
5. GET /v2/auto/queries/{queryId}/stream — Stream notifications (or poll)
6. GET /v2/auto/queries/{queryId}/sessions + /sessions/{sessionId} — Fetch LLM output (if using llm action)
7. (Optional cleanup) POST /v2/auto/queries/{queryId}/cancel — Cancel only while active (returns 409 if already terminal)
8. (Optional cleanup) DELETE /v2/auto/queries/{queryId} — Delete only after terminal (triggered / expired / cancelled / failed); rejects active queries with 409

x402 mode (/x402/v2/auto/*):

1. POST /x402/v2/auto/chat — Ask Builder Chat to draft a query
2. POST /x402/v2/auto/queries/validate — Validate EQL and preview cost
3. POST /x402/v2/auto/queries — Create and activate
4. GET /x402/v2/auto/queries/{queryId}/stream — Stream notifications (or poll via POST)
5. POST /x402/v2/auto/queries/{queryId}/sessions + /sessions/{sessionId} — Fetch LLM output
6. (Optional cleanup) POST /x402/v2/auto/queries/{queryId}/cancel — Cancel only while active. (x402 has no terminal-delete endpoint.)

Always validate before create. Validate returns structured errors you can iterate on without spending credits.

Failure handling order (apply in sequence):

1. Retry transient network errors with exponential backoff.
2. On 400 / 422 validation failure → repair query using Validation Errors table, re-validate.
3. On 401 / 403 auth failure → refresh credentials or verify Auto is enabled for the API key.
4. On 402 x402 payment failure → re-price and retry with valid payment payload.
5. On 410 (SSE stream closed) → re-open stream or fall back to polling.

Common agent flows:

Poll-based LLM flow:

POST /v2/auto/queries                               → create query with action.type = "llm"
GET  /v2/auto/queries/{queryId}                     → poll until execution with sessionId appears
GET  /v2/auto/queries/{queryId}/sessions/{sessionId} → fetch full analysis

Webhook-based LLM flow:

POST /v2/auto/queries                               → create with action.type = "llm" and params.objective
(wait for webhook)                                  → receive session reference / output
(optional) GET session fetch                        → /v2/auto/queries/{queryId}/sessions/{sessionId}

Builder Chat

Builder Chat (POST /v2/auto/chat or POST /x402/v2/auto/chat) uses AI to translate natural language into EQL queries. Use sessionId for multi-turn conversations.

{
  "message": "Alert me when BTC breaks 100k with RSI confirmation above 55",
  "speed": "expert",
  "sessionId": "optional-session-id"
}

Response (API-key mode):

{
  "sessionId": "session-uuid",
  "response": "I can help with that... (markdown + EQL JSON code block)",
  "title": "BTC Breakout Alert",
  "reasoning": null,
  "planIds": []
}

The response message contains the AI's reply in Markdown. When it generates EQL, it will be in a JSON code block — extract, validate via /queries/validate, then submit via /queries.

Prompting tips for Builder Chat:

• Include title and description (shown in notifications so recipients know what fired hours/days later)
• Specify symbols, timeframe, trigger behavior (one-time — the default — vs recurring), delivery target. For recurring on the same condition, ask for the repeat object (cooldown + maxTriggers); for a fixed schedule, use a cron condition
• For Signal triggers, give a factual match description (avoid vague phrasing like "bullish vibes")
• Append "If anything is unsupported, return the closest supported query and list substitutions" to handle edge cases gracefully
• Prefer expiresIn of 24h–3d for fresh signals
• Persist sessionId and reuse it for follow-up prompts so the model keeps context across turns

High-impact prompt pack — drop these into POST /v2/auto/chat as the message field:

1) Complex TA breakout with direction filter:

Build an Auto query:
- title + description: short human-readable summary and 1-2 sentence thesis
- symbols: BTC, ETH, SOL
- timeframe: 5m
- trigger when price breaks previous 1h range high or low
- confirm direction with RSI(14): >55 for upside, <45 for downside
- actions: telegram alert + webhook to https://your-runner.example/auto/even