Crypto News HTTP API

Use when calling the Crypto News Analyzer HTTP API for async analysis jobs, semantic search, datasource management, or health checks from OpenClaw.

Security Scan

The skill largely matches a simple HTTP API client (Bearer API_KEY) but the docs reference additional secrets and runtime dependencies that are not declared, creating an incoherence you should clarify before installing.

Purpose & Capability

Name/description match the instructions: this is an HTTP client for the Crypto News Analyzer API and correctly requests a bearer API_KEY. That primary credential is proportionate to the stated purpose. However, the docs also mention other service-side keys (OPENAI_API_KEY, KIMI_API_KEY, GROK_API_KEY, TELEGRAM_WEBHOOK_PATH) which are not declared in the skill metadata — it's unclear whether the agent/user must supply them or they are server-only. This missing justification is a notable mismatch.

Instruction Scope

SKILL.md instructs the agent how to call the API (POST /analyze, poll status, fetch results), how to store the API key in openclaw.json, and when to prefer local base URLs. It does not direct the agent to read arbitrary host machine files or exfiltrate data. References describe server-side webhook handling and header validation; those are operational notes, not instructions for the agent to access secrets on the client machine.

Install Mechanism

This is an instruction-only skill with no install spec and no bundled code — lowest-risk install mechanism (nothing is downloaded or executed on install).

Credentials

The skill metadata declares a single primaryEnv (API_KEY) which is appropriate. But the documentation repeatedly references additional API keys and environment variables (OPENAI_API_KEY, KIMI_API_KEY, GROK_API_KEY, TELEGRAM_WEBHOOK_PATH, X-Telegram-Bot-Api-Secret-Token). These are not declared in requires.env. It's ambiguous whether these are server-side dependencies (likely) or credentials expected from the OpenClaw environment. That ambiguity increases risk because you might be asked later to provide sensitive keys unrelated to the simple bearer API token.

Persistence & Privilege

Skill is not always:true and does not request persistent system privileges. It only suggests storing the API key in OpenClaw's user config (openclaw.json), which is normal for skills that need an API token.

What to consider before installing

This skill appears to be a straightforward HTTP client that needs a bearer API_KEY — that part is coherent. Before installing: 1) Confirm whether semantic-search features require you to provide OPENAI_API_KEY, KIMI_API_KEY, or GROK_API_KEY in your OpenClaw environment (the docs mention them but the skill metadata does not). 2) Verify the API host (https://news.tradao.xyz) is trusted for your data and that you’re comfortable sending your API_KEY there; consider using a local/private deployment if available. 3) Note the Telegram webhook is maintainer-facing; you will not be asked by the skill to expose your Telegram bot secret unless you explicitly configure webhook integration. 4) Because this is instruction-only, it won't install binaries, but the missing declaration of additional keys and server-side dependencies is the main inconsistency — contact the publisher or inspect the API server code/tests (referenced in the docs) to confirm which credentials are required client-side. If you cannot get that clarification, avoid providing extra secrets beyond the bearer API key.

Crypto News HTTP API Skill

This skill helps OpenClaw interact with the Crypto News Analyzer HTTP API for asynchronous news analysis, semantic search, datasource management, and operational monitoring.

When to Use

Use this skill when you need to call https://news.tradao.xyz or a local deployment of the same API.

Typical triggers:

• Run asynchronous crypto news analysis over a time window
• Run asynchronous semantic search for a freeform topic query
• Poll an API job until it finishes and then fetch the final result
• Create, list, or delete datasources through the HTTP API
• Check service health before or after an API workflow

Quick Reference

Authentication is Bearer token style: send Authorization: Bearer <API_KEY> with every request.

The core analysis workflow is asynchronous. POST /analyze creates a job and returns immediately. It does not return the final report. You must poll for 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.

Semantic search follows the same async pattern. 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:

• Analyze Workflow Reference
• Semantic Search Reference
• Datasource Management Reference
• Operations and Maintenance Reference

OpenClaw Setup

Install this skill into <workspace>/skills, <workspace>/.agents/skills, ~/.agents/skills, or ~/.openclaw/skills. Start a new OpenClaw session after installing or updating the skill so the refreshed snapshot is picked up.

This skill declares metadata.openclaw.primaryEnv: API_KEY. In OpenClaw, you can inject the bearer token for each run through ~/.openclaw/openclaw.json:

{
  skills: {
    entries: {
      "crypto-news-http-api": {
        enabled: true,
        apiKey: "YOUR_API_KEY"
      }
    }
  }
}

If you are using a non-production deployment, replace https://news.tradao.xyz with your local or private base URL in each request you issue.

Analyze Workflow

Create an analysis job by posting to /analyze with hours (how far back to look) and user_id (your agent identifier). 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 report from the result URL.

This pattern keeps long-running analysis work from blocking your client and lets you track progress transparently.

Semantic Search

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 integer
• query is required, trimmed, and capped at 300 characters
• query cannot be blank or whitespace-only
• user_id must match ^[A-Za-z0-9_-]{1,128}$

Operational constraints:

• Semantic search is PostgreSQL-only and returns 503 when the backend does not support pgvector
• The API uses vector similarity over stored content embeddings and may combine that with keyword retrieval
• Query decomposition is capped at 4 subqueries
• Final retained results are capped at 200 unique items
• Embedding generation requires OPENAI_API_KEY; query planning and report synthesis require KIMI_API_KEY or GROK_API_KEY

The result body returns a Markdown report with query, normalized_intent, matched_count, retained_count, time_window_hours, and report. The report is structured for direct agent consumption with a normalized intent summary and cited signal blocks.

Datasource Management

Configure news 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.

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 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.

Telegram Webhook

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.

Endpoint Index

Supported HTTP routes:

• GET /health - Service health check
• POST /analyze - Create an analysis job (async, returns 202)
• GET /analyze/{job_id} - Check job status
• GET /analyze/{job_id}/result - Retrieve completed job results
• POST /semantic-search - Create a semantic search job (async, returns 202)
• GET /semantic-search/{job_id} - Check semantic search job status
• GET /semantic-search/{job_id}/result - Retrieve completed semantic search results
• POST /datasources - Create a datasource
• GET /datasources - List all datasources
• DELETE /datasources/{id} - Delete a datasource
• POST /telegram/webhook - Telegram webhook receiver

Non-Goals

This skill does not cover:

• Telegram slash commands (use the Telegram bot directly)
• Autogenerated documentation routes (/docs, /redoc, /openapi.json)
• Deprecated compatibility aliases (api-server, crypto-news-api)
• Direct embedding backfill operations beyond pointing you to the documented command

These surfaces exist but are intentionally excluded from this API-focused skill.

Updating

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 and tests first, then reference files, then guides.