Metered API Marketplace

Build and operate a metered public API endpoint ("agent microservice") for OpenClaw skills/agents with API-key auth, per-request usage logging + pricing, pre...

Security Scan

The skill's code and runtime instructions match the described metered-API functionality, but the registry metadata omits many required environment/credential inputs and there are configuration/installation gaps that don't add up and deserve closer review before deploying.

Purpose & Capability

The name/description (metered public API with API-key auth, usage ledger, and payment webhooks) are consistent with the bundled server and Next.js reference code. However, the published metadata declares no required environment variables or credentials even though the code expects a Postgres DATABASE_URL, ADMIN_TOKEN, webhook secrets, fee addresses, and other env vars — a clear mismatch between stated registry requirements and actual runtime needs.

Instruction Scope

SKILL.md and the references document the expected workflow (pick transformer, run the server, create API keys, wire webhooks, deploy behind TLS). The runtime instructions and code operate within that advertised scope (authenticate signed API keys, check balances, deduct per-call cost, verify provider webhooks). The instructions do not direct the agent to read unrelated local system files or exfiltrate secrets, but they do require you to provide sensitive configuration (DB URL, webhook secrets, admin token).

Install Mechanism

There is no install spec in registry metadata (instruction-only), but the package contains runnable Node.js code (server and Next.js starter) that requires npm dependencies (next, pg, fastify, @fastify/rate-limit, etc.). This means the user/installer must run npm install / deploy themselves; nothing is downloaded from an untrusted URL, but the lack of an explicit install step in metadata is a usability/security gap (operators might not realize what will be required).

Credentials

Registry metadata lists no required env vars or credentials, yet the code and SKILL.md expect many sensitive env vars: DATABASE_URL (Postgres connection string), ADMIN_TOKEN, WEBHOOK_SHARED_SECRET, COINBASE_COMMERCE_WEBHOOK_SECRET, BTCPAY_WEBHOOK_SECRET, FEE_BPS, FEE_ETH_ADDRESS, FEE_BTC_ADDRESS, COST_CENTS_PER_CALL, MAX_BODY_BYTES, MAX_SKEW_MS, PORT/HOST, etc. Requesting a DB connection string and multiple webhook secrets is proportional for a hosted payments/ledger service, but the omission from metadata is an incoherence and a potential safety/permission model problem (user may not be warned up-front).

Persistence & Privilege

The skill does not request always:true, does not claim to modify other skills, and does not embed persistent platform-level privileges. It implements its own runtime server and DB records (api_keys, balances, usage, credits) which is normal for the stated purpose. Be aware running this creates a long-lived external service with its own credentials and webhooks.

What to consider before installing

This package appears to be a coherent metered-API reference implementation, but pay attention before installing or deploying: - Metadata mismatch: the registry lists no required env vars, but the code requires a Postgres DATABASE_URL and several secrets (ADMIN_TOKEN, webhook secrets, fee addresses). Treat DATABASE_URL and webhook secrets as high-sensitivity credentials — granting them equals giving the service access to your database and to credit balances. - Do not deploy with default/empty secrets. Set a strong ADMIN_TOKEN and unique WEBHOOK_SHARED_SECRET / provider webhook secrets before exposing admin endpoints. - Admin endpoints (create-key, stats) exist — ensure these are protected by ADMIN_TOKEN and not public. If you deploy to a public host, restrict access (IP allowlist, additional auth) or remove admin routes from the public surface. - The service requires a Postgres DB. Run it in an isolated project/account and avoid reusing a production database or credentials. - Verify webhook handling and fee addresses. The server only accounts for bookkeeping; on-chain custody/splitting must be handled by your payment processor. Double-check fee calculations and where fee addresses are configured. - Installation/Deployment: because there is no install spec, you (or your operator) will need to run npm install and manage deployment. Review package.json, pin dependency versions, and run dependency audits (npm audit / SCA) before deploying. - Review the code yourself (or have an engineer review) for any environment-specific assumptions you may need to change (rate limits, pricing envs, MAX_BODY_BYTES). The transformer functions are deterministic and do not make outbound network calls, which reduces exfiltration risk, but the DB/webhook code will handle sensitive data. If you want to proceed, require the publisher to update registry metadata to explicitly declare required env vars and permissions, or only run the reference implementation in an isolated/test environment until you are comfortable with configuration and security controls.

Provide a production-lean template for: OpenClaw Skill → Public API Endpoint → Usage Metering → Crypto Payment Gateway → BTC/ETH wallets.

This skill ships a runnable reference server (Fastify + SQLite) that:

• Accepts structured JSON input
• Performs a high-value transformation (pluggable “transformers”)
• Returns structured JSON output
• Enforces signed API key auth
• Checks prepaid balance, deducts per call, and logs usage
• Accepts payment webhooks (Coinbase Commerce / BTCPay Server style)
• Applies a 2.5% platform fee in the ledger (fee addresses configurable)

Workflow (do this in order)

1) Pick the productized capability (the thing people pay for)

Choose ONE transformer that is:

• high leverage (makes/keeps money)
• repeatable (called often)
• defensible (data, heuristics, workflow, or automation — not “generic summarization”)

Good defaults:

• revenue/offer optimizer
• ad copy optimizer
• lead scoring
• contract risk flags

If unclear, start with the included revenue-amplifier transformer and replace it later.

2) Run the reference server locally

Use the bundled server in scripts/server/.

Typical run:

• cd scripts/server
• npm install
• cp .env.example .env and edit
• npm run dev

Set flat launch pricing in .env:

• COST_CENTS_PER_CALL=25 # $0.25/call

3) Create an API key

Use scripts/server/admin/create_key_pg.js (or the admin HTTP endpoint) to create a key and starting balance.

4) Integrate from an OpenClaw skill / agent

Call the public endpoint with:

• x-api-key
• x-timestamp (unix ms)
• x-signature = hex(HMAC_SHA256(api_secret, ${timestamp}.${rawBody}))

5) Add real payments

Wire a payment processor webhook to /v1/payments/webhook/:provider.

Providers are adapter-based:

• start with “manual” credits (admin script)
• then add Coinbase Commerce or BTCPay Server

6) Ship

Deploy behind TLS (Cloudflare / Fly.io / Render / AWS / GCP). Put rate limiting at the edge + in-app.

Bundled resources

scripts/server/

Runnable reference implementation:

• Fastify API server (long-running)
• Postgres ledger (balances, usage, credits)
• Signed API key auth
• Rate limiting + basic anti-abuse
• Webhook endpoint(s)

scripts/nextjs-starter/

Vercel-ready Next.js API implementation:

• Serverless API routes (no listen())
• Postgres ledger (Supabase Transaction Pooler recommended)
• Same auth + pricing + webhook concepts

references/

Read only when needed:

• references/api_reference.md – endpoint contracts + auth/signing
• references/billing_ledger.md – pricing, fee logic, idempotency
• references/providers.md – provider adapters (Coinbase/BTCPay patterns)