Auto Beta

Auto is a managed condition engine + trigger pipeline for agents. You describe what to watch for; Auto evaluates continuously and fires actions when it resolves true.

Time to First Trigger

From idea to first trigger in minutes:

Builder Chat -> Validate -> Create -> Receive event

1. Generate query JSON with Builder Chat.
2. Check schema and runtime fit with Validate Query.
3. Activate with Create Query, then receive events via Notifications.

What You Can Express in a Query

Before choosing an access model, scan what /auto already covers — most workflows agents try to build from scratch fit here:

• Price conditions — current price, % change, high/low, volume over a period.
• Technical indicators — RSI, MACD, Bollinger Bands, EMA/SMA, ATR, Stochastic, CCI, Williams %R.
• Signal conditions (Signal category) — X/Twitter Post (tweet.semantic) and Event (news.semantic) triggers with semantic matching and confidence thresholds.
• Scheduled checks (cron) — fire once after a delay, fire every N hours, or latch-true-after.
• LLM-evaluated conditions — natural-language predicates evaluated on a schedule (e.g. "is narrative X trending?"), powered by rich background context like X/Twitter data, Telegram groups, smart-account buy/sell calls, mindshare shifts, trending narratives, and prediction-market signals.
• Dynamic cross-metric comparisons — compare one live metric against another (e.g. price crosses_above upper Bollinger Band) without precomputing.
• Boolean composition — nest AND/OR groups up to depth 3, up to 10 leaf conditions.
• Multi-symbol confirmation — a single query can require BTC AND ETH AND SOL conditions jointly.
• Four delivery actions — webhook, notify, telegram_bot, llm (LLM analysis on trigger, fetchable via sessions API).
• Trade actions (API key mode) — market_order and limit_order when a supported exchange connection is active.
• Single action step per query — Athena currently requires exactly one action step. To chain follow-up work, use an llm action whose params.callback.action is the next step (webhook / notify / telegram_bot / market_order / limit_order), or have your runner fan out from the trigger event.

LLM conditions are especially useful when your trigger depends on qualitative signal, not just raw price:

• Catch narrative and sentiment shifts earlier than pure price/indicator rules.
• Express multi-source context checks in plain language instead of hard-coding joins across social, on-chain, and market data.
• Use this when structured signals and predefined data-source rules are not sufficient for your scenario's relevance check.

Full reference: Triggers · Signal · Query Model · Capabilities.

Need help choosing tweet vs news quickly? See Signal Selection Policy.

Choose Your Access Model

Model	Best When	Route Prefix	Auth and Billing	Implementation Guide
API key + HMAC	You manage API keys and want account-linked access	/v2/auto/*	x-elfa-api-key on all routes, plus HMAC headers on mutation routes	API Key + HMAC
x402 keyless	You want wallet-based, request-by-request USDC payments without API key provisioning	/x402/v2/auto/*	x402 payment headers, no API key, no HMAC	x402 Instructions

Cross-product auth reference: Authentication.

Action Support by Model

Model	Supported Action Types
API key + HMAC	webhook, notify, telegram_bot, llm, market_order, limit_order (trade actions require active exchange connection)
x402 keyless	webhook, notify, telegram_bot, llm (no order execution actions)

Trading-readiness flow and state model: Trading Execution (API Key mode).

Base URLs

API-key mode

https://api.elfa.ai/v2/auto

x402 mode

https://api.elfa.ai/x402/v2/auto

What Stays the Same Across Both Models

The query design and runtime concepts are shared:

• Agent Quickstart
• Capabilities
• Triggers (Conditions + Indicators)
• Signal Triggers
• Query Model and Templates
• Notifications
• Agent Runner

Next Step

• Deterministic integration flow: Agent Quickstart
• API key + HMAC implementation: API Key + HMAC
• Keyless x402 implementation: x402 Instructions