Install
openclaw skills install smart-newsUse when calling the Crypto News Analyzer HTTP API for async analysis jobs, semantic search, datasource management, intelligence operations, or health checks from OpenClaw.
openclaw skills install smart-newsUse this skill to call the Crypto News Analyzer HTTP API from OpenClaw.
Use this skill when you need to call https://news.tradao.xyz or a compatible private deployment.
Typical triggers:
Authentication is Bearer token style: send Authorization: Bearer <API_KEY> with every request.
POST /analyze creates a job and returns immediately. It does not return the final report. Poll status, then fetch the result.
Workflow: POST /analyze -> GET /analyze/{job_id} -> GET /analyze/{job_id}/result
Jobs move through these states: queued, running, completed, failed.
POST /semantic-search creates a job, returns 202 Accepted, and includes status_url, result_url, plus a Retry-After header.
Semantic workflow: POST /semantic-search -> GET /semantic-search/{job_id} -> GET /semantic-search/{job_id}/result
Semantic search requires PostgreSQL with pgvector. SQLite runtime is unsupported.
For detailed guides, see:
This skill declares metadata.openclaw.primaryEnv: API_KEY. In OpenClaw, inject the bearer token through ~/.openclaw/openclaw.json:
{
skills: {
entries: {
"smart-news": {
enabled: true,
apiKey: "YOUR_API_KEY"
}
}
}
}
If apiKey is unavailable, do not send unauthenticated requests. Ask the operator to configure the token first.
If you are using a non-production deployment, replace https://news.tradao.xyz with the correct base URL before issuing requests.
Create an analysis job by posting to /analyze with hours and user_id. The server responds with 202 Accepted, a job_id, status_url, and result_url.
Poll the status endpoint until the job reaches completed or failed. Do not expect the analysis report in the initial POST response. Once completed, fetch the result URL.
Create a semantic search job by posting to /semantic-search with hours, query, and user_id. The server responds with 202 Accepted, a job_id, status_url, and result_url. Semantic search job IDs start with semantic_search_job_.
Poll the status endpoint until the job reaches completed or failed, then fetch the report from the result URL. Use the status field as the source of truth for lifecycle state; success becomes true only when the job is completed successfully.
Request rules:
hours must be a positive integerquery is required, trimmed, and capped at 300 charactersquery cannot be blank or whitespace-onlyuser_id must match ^[A-Za-z0-9_-]{1,128}$Operational constraints:
503 when the backend does not support pgvectorOPENAI_API_KEY; query planning and report synthesis require KIMI_API_KEY or GROK_API_KEYThe result body returns a Markdown report with query, normalized_intent, matched_count, retained_count, time_window_hours, and report.
Configure news and intelligence sources through the datasource API. Create sources with POST /datasources, list them with GET /datasources, and remove them with DELETE /datasources/{id}. All datasource routes require Bearer auth.
Each datasource has a purpose field: news (RSS/X/REST feeds for analysis) or intelligence (Telegram groups, V2EX for topic research). The GET /datasources endpoint supports optional purpose and source_type query parameters for filtering. Results are sorted by purpose, source type, then name.
Tags help organize sources. Each datasource accepts up to 16 unique tags. Each tag is capped at 32 characters. Tags are normalized to lowercase and deduplicated automatically.
List and create responses include only safe summaries. For rest_api type datasources, secrets are redacted and counts replace raw credential fields. This prevents accidental credential exposure when reviewing configurations.
All intelligence routes require Bearer auth. The deprecated entry-based routes (/intelligence/entries*, /intelligence/discovery, /intelligence/labels, /intelligence/search) have been removed in the topic-only refactor. Topics are the sole first-class intelligence objects, driving scheduled LLM research from raw ingested messages and storing findings with merge support.
Synchronous topic workflow endpoints:
POST /intelligence/topics — Create a topic draft from a user theme (returns AI-generated prompt draft)POST /intelligence/topics/{topic_id}/revise — Revise the draft prompt with feedbackPUT /intelligence/topics/{topic_id}/prompt — Manually set/replace the prompt text (context-aware: edits active prompt if one exists, otherwise creates draft revision)POST /intelligence/topics/{topic_id}/confirm — Confirm and activate the topic for research (requires prompt_version_id)GET /intelligence/topics — List topics with pagination and active_only filter (default: true)GET /intelligence/topics/{topic_id} — Get topic detail including prompt versions, active findings, citations, merge availability, and recent run logsPOST /intelligence/topics/{topic_id}/merge-preview — Create a merge preview from active findings (requires prompt_version_id)POST /intelligence/topics/{topic_id}/merge-accept — Accept a merge preview (archives source findings, creates merged finding; requires preview_id)POST /intelligence/topics/{topic_id}/pause — Pause topic researchPOST /intelligence/topics/{topic_id}/archive — Archive a topicGET /intelligence/topics/{topic_id}/runs — List research run logs for a specific topic (supports run_type filter)GET /intelligence/topic-runs — List topic research run logs across all topics with optional filters (topic_id, run_type)These endpoints are synchronous; there is no async job/poll flow. Results return immediately.
Topics have lifecycle states: draft, active, paused, archived. Only active topics are researched by the ingestion scheduler. Merge previews expire after 24 hours. Accepting a preview archives the exact source findings bound to it; stale previews (where active findings changed) are rejected.
The webhook endpoint exists for maintainer-level Telegram integration. It is not the primary path for day-to-day operators. Regular users should interact through the API routes or Telegram slash commands instead.
When processing webhook updates, validate the X-Telegram-Bot-Api-Secret-Token header to confirm the request originates from Telegram.
Supported HTTP routes:
GET /health - Service health checkPOST /analyze - Create an analysis job (async, returns 202)GET /analyze/{job_id} - Check job statusGET /analyze/{job_id}/result - Retrieve completed job resultsPOST /semantic-search - Create a semantic search job (async, returns 202)GET /semantic-search/{job_id} - Check semantic search job statusGET /semantic-search/{job_id}/result - Retrieve completed semantic search resultsPOST /datasources - Create a datasourceGET /datasources - List all datasourcesDELETE /datasources/{id} - Delete a datasourcePOST /telegram/webhook - Telegram webhook receiverPOST /intelligence/topics - Create topic draft (synchronous, Bearer-protected)POST /intelligence/topics/{id}/revise - Revise topic promptPUT /intelligence/topics/{id}/prompt - Manually set topic promptPOST /intelligence/topics/{id}/confirm - Confirm and activate topicGET /intelligence/topics - List topics with status filtersGET /intelligence/topics/{id} - Get topic detail with findingsPOST /intelligence/topics/{id}/merge-preview - Create merge previewPOST /intelligence/topics/{id}/merge-accept - Accept merge previewPOST /intelligence/topics/{id}/pause - Pause topicPOST /intelligence/topics/{id}/archive - Archive topicGET /intelligence/topics/{id}/runs - List per-topic research run logsGET /intelligence/topic-runs - List global topic research run logsThis skill does not cover:
/docs, /redoc, /openapi.json)api-server, crypto-news-api)These surfaces exist but are intentionally excluded from this API-focused skill.
Keep this skill aligned with the live HTTP routes in api_server.py, the AI Analyze API Guide at docs/AI_ANALYZE_API_GUIDE.md, and the semantic search guide at docs/SEMANTIC_SEARCH_API_GUIDE.md.
When documentation disagrees with implementation, trust the code and tests over prose docs. Source precedence: code first, then reference files, then guides.