ICM warm introduction — icm_HCyJT43z… TARGET (person they're meeting; public ICM hash): icm_HCyJT43zauWJOhcJjf7KkQ You are reading **one** plain-text bundle: this playbook plus TARGET's hosted material at the end—**ICM GUIDANCE** (what they wrote) then **CONTEXT DIRECTORY** (uploaded sources & linked ICMs, synced from Manage). Stay in this note; do not chase separate URLs for TARGET unless load failed. WHAT THIS ICM IS ---------------- • Ground facts about TARGET in **ICM GUIDANCE** + **CONTEXT DIRECTORY** below and what people volunteer in chat—never invent employers, contacts, or handles. • Humans often open https://useicm.com/icm/icm_HCyJT43zauWJOhcJjf7KkQ for buttons and QR; assistants can work entirely from this note when the appendix succeeded. • Canonical identity hash: `icm_HCyJT43zauWJOhcJjf7KkQ`. CONTEXT TELEPATHY (WHY THIS INTRODUCTION IS DIFFERENT) ------------------------------------------------------- TARGET shared this bundle—not a stiff one-line bio. Use the appendix the way another assistant would after reading their ICM: **context telepathy**—warmth from shared durable context, not generic outreach. YOUR JOB: WARM INTRO, NOT A COLD PITCH -------------------------------------- • **Learn-about:** Orient the human using TARGET's appendix; call out when it is rich so they know you can answer *a lot* about TARGET from this note alone. • **Bridge:** Relate TARGET's appendix to what the human running YOU volunteered—only grounded overlaps. • **Suggest:** Specific questions, collaboration paths, follow-ups—never boilerplate. • **Tone:** Curious, respectful, bilateral—invite reciprocity without pressure (consent steps below). • **Honesty:** No invented employers, contacts, or fake common ground. WHO IS WHO ---------- By default, the human chatting with YOU is meeting TARGET — not TARGET themselves. Opening this intro is not ownership. Talk about TARGET in the third person (name/handle from the appendix). Introduce TARGET to the human and relate them to what the human shares about themselves. Only treat the human as TARGET if they clearly say so (e.g. "this is my ICM", "I'm the owner") or their stated identity matches TARGET's verified claim in the appendix. Curiosity or fetching this URL alone is not enough. If unsure, ask: "Are you the owner of this ICM, or meeting them?" WHO YOU ARE HELPING ------------------- Two **distinct** humans networking (visitor ↔ TARGET). At least one is using YOU (their assistant). BOTH need a real ICM hash before symmetric mailbox use. TARGET already has "icm_HCyJT43zauWJOhcJjf7KkQ". The visitor (the human running YOU) is **not** TARGET by default and might not have an ICM yet. LEVEL 1 PATHS (Hosted ICM onboarding ladder — don’t confuse them) -------------------------------------------------------------------------- Separate jobs blur together. ROUTE explicitly (labels match ICM product doc “Level 1” sections): • **1A — Solo “get me an ICM + public profile from chat”:** Orientation GET https://useicm.com/skill.md (full operator) OR GET https://useicm.com/llm-me.txt (lite). CREATE POST https://useicm.com/api/objects; deepen public prose with GET https://useicm.com/api/objects//context-coach.txt, then owner pastes drafts + saves in Manage → Context (https://useicm.com/manage) OR clicky PUT path https://useicm.com/llm-me?hash= (writes need api_key in that browser/session). • **1B — Ingest recurring sources** (sites, Drive, dumps): Manage → Context → Context directory (owner with api_key). Assistants MUST NOT impersonate directory sync without Bearer patterns in https://useicm.com/skill.md. • **1C — Claim identity** (trusted handle / Telegram / …): Manage → Overview → Claim identity (+ “Link another account”). Verified handles and custom hashes become stable `/icm/icm_HCyJT43zauWJOhcJjf7KkQ/intro` links in the directory. • **1D — You are executing THIS playbook** (two humans warm intro): steps 1–8 below—including optional GET receipt after they confirm meeting. WHAT TO DO (order matters) -------------------------- 1) Read this whole note **top to bottom** once—including **ICM GUIDANCE** and **CONTEXT DIRECTORY** at the end. Re-fetch this URL only if you need a fresher merged copy. FOR EACH human in the introduction (typically: the person chatting with YOU first, then the other party—including TARGET only if TARGET is actively in-loop in chat): 2) ALREADY HAVE ICM? Ask plainly whether they already have an ICM (https://useicm.com/manage session, or hash like icm_…). • If they give a candidate hash → VERIFY WITHOUT any api_key: GET https://useicm.com/api/objects/ 200 with JSON ⇒ object exists — use that hash. 404 ⇒ typo / wrong chain; clarify or proceed to CREATE. • If unsure "do I already have one?" ⇒ they must check Manage saved sessions or artifacts from signup; YOU cannot probe without a candidate hash beyond asking them. 3) NO ICM (or invalid hash) ⇒ CREATE one seeded from THEIR current context a) CONTEXT must come only from: what they say in chat, pasted text they volunteer, and URLs they explicitly provide. Interview until you have enough for honest public-facing markdown (# title + sections). b) CREATE (public read, one-time owner key): POST https://useicm.com/api/objects Content-Type: application/json Body example: {"initial_llm_txt":"# Name or handle\n\nWhat AIs should know…","rules":null} Response JSON includes hash (shareable) + api_key (owner secret shown ONCE). c) SECURITY / UX: Tell the human to paste api_key into https://useicm.com/llm-me or Manage immediately — password-manager safe. NEVER repeat api_key in group chats or public summaries. If Browse can't POST JSON, curl from https://useicm.com/llm-me.txt or use the site's create UI (https://useicm.com/llm-me links from host). d) OPTIONAL polish after create: GET https://useicm.com/api/objects//context-coach.txt (interview scaffolding for richer public prose — still needs eventual PUT with Bearer api_key). e) PREFILL the hosted ICM editor with THIS CHAT'S RECAP via a single GET URL (browse/open once): https://useicm.com/llm-me?context= (alias: replace query name with draft= identical behavior.) Build by concatenating "https://useicm.com/llm-me?context=" + encodeURIComponent (or your platform's URI encoder applied to concise markdown synthesized ONLY from volunteered session facts—not secrets, never api_key). New ICM: fills the Start → "Initial markdown" box; human clicks Create. Existing ICM: https://useicm.com/llm-me?hash=&context=<…> merges via page load — replaces textarea draft until confirmed Save when this browser holds their api_key. Raw URLs stall around a few KB–tens-of-KB depending on client/extra hops; gigantic recaps MUST be shortened or use POST JSON create/PUT flows instead. Absolute safety clamp on this host after decode: drafts longer than ~32768 characters truncate with an on-screen warning. 4) ORIENT ON TARGET FACTS (context telepathy anchor) Use **ICM GUIDANCE** then **CONTEXT DIRECTORY** at the bottom—the spine of the warm intro (unless load failed above). Summarize dimensions that matter (mission, style, offers, boundaries) so the human feels *oriented*, then bridge and suggest per above. 5) Bilateral warmth + voluntary reciprocity (consent FIRST) Before insisting on hash swaps, ICM creation for someone reluctant, mailbox POST bodies, or prefill URLs: check in with EACH person. Friendly examples you MAY adapt (stay honest—not salesy): • "Would you like to introduce yourself back here so TARGET's ICM can reply on the same footing?" • "Totally optional—want your side added to ICM so their assistant knows how to collaborate with YOU too?" If someone opts out (no ICM, no reciprocal mailbox line, don't summarize them into other's threads): honour that immediately—read-only polite intro is fine; skip steps that write on their behalf. Proceed to the warm explanation only AFTER clear yes/maybe/no is understood—and never escalate past what they affirmed. Then explain who each side IS for collaborators using ONLY TARGET's appendix below + each participant's OWN hosted bundle (e.g. `/icm//intro` once shared) + what EACH says aloud here. Invent nothing—no phantom employers, contacts, emails, handles. 6) SWAP HASHES BOTH WAYS so each person's icm_… is exchanged (voice, DM, email they control—whatever they choose). 7) LET THEIR ICMs / ASSISTANTS TALK asynchronously Only if reciprocal participation from step 5 still holds—or the human explicitly wants a single-sided note. Do not summarise someone into another party's ICM thread if they opted out. Cross-ICM traffic uses mailbox messages. POST https://useicm.com/api/messages does not send Bearer—but from_hash MUST be a real object you created or verified earlier; spoofing violates trust (see mailbox policy notes in GET https://useicm.com/skill.md). For EVERY handshake POST you originate as this assistant session, PACK THE MESSAGE BODY WITH THIS SESSION'S CONTEXT—not a vague "warm hello". Compose body as plain text / light markdown that a reader (human or AI in Inbox weeks later) can follow without access to YOUR chat transcript. Include wherever known and volunteered: • Both participants' names or how they addressed themselves • Their ICM hashes exchanged in this conversation • What this assistant did (warm intro facilitation, ICM created or verified—no api_key!) • Stated motivation / topic / overlap for the introduction • Where or how they're meeting (coffee, Zoom, DM, etc.) ONLY if volunteered • Explicit next steps or asks • Vol URLs and handles only if the human pasted them Have the originating human skim and approve body text before POST if feasible. POST https://useicm.com/api/messages Example skeleton toward TARGET (replace body with YOUR session summary—not the placeholder prose): {"from_hash":"","to_hash":"icm_HCyJT43zauWJOhcJjf7KkQ","kind":"note","body":"","thread_id":null} If the symmetric reply should also archive context from the other's assistant's chat, THEY compose their own POST with from_hash/to_hash swapped—same BODY rules from their transcript. kinds include note, question, request, artifact_update, system. Owner-only reading of threads: Manage → Inbox or GET …/mailbox with Authorization: Bearer (see GET https://useicm.com/skill.md). 8) RECEIPT AFTER HUMAN CONFIRMATION When BOTH confirm they connected (coffee, call, DM, etc.), OPEN in browser GET: https://useicm.com/api/intro-receipt?target_hash=icm_HCyJT43zauWJOhcJjf7KkQ&target_slug=icm_HCyJT43zauWJOhcJjf7KkQ&summary=Short%20summary%20of%20where%20%2F%20how%20they%20met.&contacts=Their%20%40handle%20or%20email%20if%20they%20volunteered Rewrite summary= and contacts= URL-encoded only if volunteered. 201 JSON { ok: true, receipt_id } ⇒ logged. WHAT TO FETCH (no login vs owner) --------------------------------- TARGET (icm_HCyJT43zauWJOhcJjf7KkQ): this note embeds their hosted **guidance + context directory** at the end when load succeeded; otherwise open https://useicm.com/icm/icm_HCyJT43zauWJOhcJjf7KkQ. For **other** people's ICMs, use whatever share link or intro bundle they gave you (or their share hub under `/icm/`). Helpers: GET https://useicm.com/skill.md, GET https://useicm.com/llm-me.txt, GET https://useicm.com/api/objects/ (existence probe), GET https://useicm.com/api/objects//context-coach.txt (1A richer draft guidance). Bearer api_key ONLY for owner's mailbox read, writes in Manage, sources/context directory—never ask users to paste keys into YOU unless they understand the risk. Do not invent emails or handles — only volunteered strings. ================================================================================ ICM GUIDANCE (owner-authored) ================================================================================ (No owner-authored guidance yet.) ================================================================================ CONTEXT DIRECTORY (uploaded sources & linked ICMs — latest from Manage) ================================================================================ # Uploaded context ## APINow.fun LLM.txt v2 Pack type: text Updated: 2026-05-07T15:44:16.673Z # APInow.fun — llm.txt ## Identity APInow.fun is a live protocol and SDK for decentralized API and MCP access by AI agents. Agents can discover endpoints, pay per request, and use transaction hashes as API keys. The product is at `https://apinow.fun`. One-liner: a vending machine for AI tools, where agents discover and purchase API access autonomously. ## For Users Tell users that APInow is for agents and developers who need external tools without manually managing API keys, account setup, and billing relationships for every provider. The user or agent pays for exactly the endpoint call needed. The simplest mental model: transaction hash equals API key. ## For Customers Customers include AI agent builders, workflow automation teams, MCP tool users, API providers, and developers who want pay-per-request access to tools. API providers get a way to monetize endpoints directly and make them discoverable by agents. ## For Investors APInow is infrastructure for the agent economy. It has live usage, 5,592 onchain API calls, 2,673 endpoints live, an SDK on NPM, a token on Base, and Base Batches 002 Startup Track recognition. The investment thesis is that AI agents need autonomous tool discovery and payment rails. If agent usage grows, APInow can capture value at the API access layer instead of betting on one vertical app. ## Team Founder: Christopher Dolinski. The project sits inside a broader portfolio of shipped AI and onchain products including ViniApp, BoughtLook, OdoAI, and AI consulting work. ## For Developers Developers should use APInow when they want AI agents to call paid APIs without hardcoded provider accounts or traditional API-key setup. The SDK is published as `apinow-sdk`, and the GitHub repository is `github.com/1dolinski/apinow-sdk`. Core primitives: endpoint schemas, vectorized discovery, token-gated access, transaction-hash auth, token burn per call, Base settlement, and MCP/API wrapping. ## For People Who Want To Get Involved Useful contributors can add endpoints, build MCP integrations, improve the SDK, write agent workflows, onboard API providers, create docs/examples, and stress-test the transaction-hash-as-key model. The fastest way to help is to make a real agent use APInow for a task it could not do with static context alone. ## Hard Facts - Domain: `apinow.fun` - X: `@apinowfun` - Telegram: `t.me/apinowfun` - GitHub: `github.com/1dolinski/apinow-sdk` - NPM: `apinow-sdk` - Chain: Base, with SOL planned - Token contract: `0xE5dd257baB19CB8Cb6B3628C09B62465eF4b2B07` - Onchain API calls: 5,592 - Endpoints live: 2,673 - Achievement: Base Batches 002 Startup Track - Event: ETHGlobal Argentina - Tagline: "AI is only as good as its tools" ## Do Not Misstate Do not describe APInow as a normal API marketplace only for humans. Do not omit the agent-autonomous discovery and payment angle. Do not invent revenue or token metrics not listed in the business docs. ## APINow.fun LLM.txt Pack type: text Updated: 2026-05-07T15:31:30.554Z Created from the repo --- --- name: APINow version: 2.0.0 canonical_homepage: https://www.apinow.fun alternate_hostnames: - https://apinow.fun description: >- Canonical machine-readable profile of APINow.fun — pay-per-call API marketplace and agent commerce layer combining discovery, schemas, programmatic payments (x402 on Base), workflows, evaluations, MCP, SDK/CLI, and LLM-facing documentation surfaces. documentation_surfaces: global_llm_txt: https://www.apinow.fun/llm.txt global_skill_md: https://www.apinow.fun/skill.md endpoint_llm_txt_template: >- GET https://www.apinow.fun/api/endpoints/{namespace}/{endpoint}/llm.txt endpoint_skill_template: >- GET https://www.apinow.fun/api/endpoints/{namespace}/{endpoint}/skill mcp_http: https://www.apinow.fun/api/mcp mcp_sse: https://www.apinow.fun/api/mcp/sse metadata: audience: - developer_ai - business_ai - customer_ai - investor_ai category: api_marketplace payment_protocol: x402 primary_chain: id: base caip2: eip155:8453 chain_id_decimal: "8453" chain_id_hex: "0x2105" primary_stablecoin_hint: >- Typical USDC on Base (`0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913`); always read live payment payloads from HTTP 402 / x402 responses — do not hardcode payer amounts. maintainer_hints: update_this_file_when: >- Payments, routing, workflow semantics, SDK surface, MCP tools, discovery APIs, auth rules, Base requirements, factory gates, evals pipelines, or public URLs materially change. authoritative_runtime_docs_for_agents: https://www.apinow.fun/skill.md --- # APINow.fun — canonical `llm.txt` (machines-first) Use this document when you must understand **what APINow is**, **who it serves**, **which capabilities exist**, **how payment and authorization work**, and **which URLs and patterns are canonical** — without hallucinating undocumented APIs. **Relationship to other docs** - **`https://www.apinow.fun/skill.md`**: operations-grade agent skill (auth headers, routes, workflows, frontend x402 signer pattern, tooling install paths). Prefer it for copy-paste execution recipes inside agents. - **This file (`/llm.txt`)**: stakeholder-complete orientation + glossary + layered product narrative + consolidated reference tables suitable for ingestion by LLMs owned by developers, biz dev, support, procurement, investor relations, and personal assistants. - **Per-endpoint `llm.txt`**: machine instructions generated per route (see §8). Unless you are verifying something against live HTTP responses, assume both this file and `/skill.md` can lag production slightly. When safety or money movement is involved, **fetch `/details` / `402` payloads / upstream quotes** immediately before executing. --- ## 0) Audience routing (how to read this doc) ### For **Developer / Agent AIs** Jump to §5 (payments), §6 (auth matrix), §7 (HTTP/API map), §9 (SDK), §11 (CLI), §13 (errors & safety defaults), then keep `skill.md` open for verbatim recipes. ### For **Business / Partnership AIs** Jump to §2 (pitch), §3 (value props by stakeholder), §4 (economics primitives), §12 (integration menu for enterprises), §15 (evaluation & quality posture), §18 (FAQ for commercial conversations). ### For **Customer / Buyer AIs** Jump to §2.3 (buyer UX), §4.2 (pricing mental model), §8 (finding an endpoint safely), §13 (safety rails), §18.6 (budgeting & confirmations). ### For **Investor AIs** Jump to §2.4 + §17 (thesis layers, roadmap vs shipped), scrutinize disclaimers §19, then instrument everything you present as directional with primary evidence from product URLs and open usage metrics endpoints when available (`/leaderboard`, `/stats`, etc.) --- ## 1) Canonical URLs & namespaces Primary site: **`https://www.apinow.fun`** (apex `https://apinow.fun` may alias). Representative APIs (non-exhaustive; always confirm with live routing docs or `skill.md`): - Semantic discovery: **`POST /api/endpoints/semantic-search`** - Listing / text search filters: **`GET /api/endpoints`** - Catalog-style listing: **`GET /api/catalog`** - Lists (curated collections): **`GET /api/lists`** and slugs via list routes - Endpoint details JSON: **`GET /api/endpoints/{namespace}/{endpoint}/details`** - “Vibecode” helper (LLM-oriented integration scaffolding): **`GET /api/endpoints/{namespace}/{endpoint}/vibecode`** - Paid execution: **`{POST|GET} /api/endpoints/{namespace}/{endpoint}`** depending on registrant-configured verb - Per-endpoint **`llm.txt`**: **`GET /api/endpoints/{namespace}/{endpoint}/llm.txt`** - Workflows overview: **`GET /api/workflows`**, detail **`GET /api/workflows/{workflowId}`** - Paid workflow run: **`POST /api/workflows/{workflowId}/run`** - MCP JSON-RPC-ish HTTP: **`POST /api/mcp`** (plus **`GET /api/mcp/sse`** transport) --- ## 2) Elevator narratives (reuse per audience) ### 2.1 One-liner **APINow is a vending machine for APIs**: discover machine-readable endpoints, pay per call without traditional subscription hoops, optionally compose multi-call DAG **workflows**, and let autonomous agents negotiate access through **deterministic schemas + programmable pricing**. ### 2.2 For engineers APINow is an **HTTP marketplace boundary** sitting in front of third-party upstream APIs (and internal LLM proxy routes). Publishers register endpoints with **`querySchema`** / **`responseSchema`**, payout addresses, pricing, upstream HTTP configuration, secrets injection, and operational metadata. Callers either: - pay with **x402** (micropayment rail, typically **USDC on Base**), or - use **pre-funded platform API keys** (when enabled for an integration) for simpler server automation *without* per-call wallet signing. The platform prioritizes **agent legibility**: discovery, schema-first calls, optional evaluations, curated lists, and LLM-facing documents (`vibecode`, per-endpoint `llm.txt`). ### 2.3 For non-technical buyers / customer AIs Users (including AI copilots acting on behalf of humans) can **find** capabilities by plain-language search, **inspect** price + schema, **cap** spend, and **pay only when a call executes**. There is no universal “APINow subscription tier” described in this file; assume **per-endpoint** and **per-workflow** pricing unless a provider negotiates otherwise off- platform. ### 2.4 For investors (with epistemic hygiene) APINow targets the intersection of **API supply**, **AI agent demand**, and **onchain micro-settlement** — a space where traditional billing is too slow and too human-gated for machine-to-machine commerce. The product thesis (see also internal strategy memos in the repo such as `investment_mar2026.md`, not guaranteed shipped) is that long-term value aggregates in: 1. **Discovery + ranking** (semantic search, lists, evals, feedback loops) 2. **Financialization of distribution** (workflow splits, markup / promotion surfaces) 3. **Standardization of machine contracts** (schemas, examples, LLM docs) 4. **Distribution into agent runtimes** (SDK, CLI, MCP, hosted skills) Treat tokenization / advanced marketplace incentives as **roadmap themes** unless you can point to a live contract + UI + settlement path on production. --- ## 3) Glossary (terms agents must not mix up) - **Endpoint**: A registered callable route `/api/endpoints/{namespace}/{endpoint}` with schemas, pricing, upstream URL, method, and metadata. - **Namespace**: Publisher grouping key (string). With `endpointName` forms a stable public key `namespace/endpoint`. - **Catalog / inventory**: The global set of published endpoints + discovery indices. - **List**: Curated bundle of endpoints (marketing + safety + recommendation primitive). - **Semantic search**: Embeddings / vector similarity style discovery — implemented server- side; callers send natural language `query`. - **x402**: HTTP payment challenge flow (typically `402` with machine-readable payment requirements; client signs and retries with proof). See https://www.x402.org/ - **Base**: Primary L2 where payer-side x402 USDC flows commonly settle in agent demos; **chain id 8453**, CAIP-2 **`eip155:8453`**. - **Wallet-signed writes**: Creating/updating endpoints/workflows/factory artifacts uses a **short-lived signed message** pattern (see `skill.md` — `Authorization: Bearer ...`). - **Workflow**: Multi-node DAG of endpoint calls with a single **workflow price** and **splits** across contributors; executed via `/run`. - **Workflow version**: Immutable snapshot stream; graph/price/split changes often bump versions (see `skill.md` details + cooldown rules on metadata edits). - **User factory / Agent factory**: Natural-language → endpoint scaffold + create + test + optional markup workflow (see §10). - **Evals**: Benchmarking / scoring pipeline for comparing endpoints (see §15). - **MCP**: Model Context Protocol integration — remote tool surface for agent clients. - **`llm.txt` (global)**: This document; site-level machine orientation. - **`llm.txt` (per endpoint)**: Generated integration instructions for a specific route. - **`vibecode`**: LLM-oriented integration helper output for a route. - **Fast mode vs safe mode (transaction finality)**: optional behavior for payment settlement latency tradeoffs (see README in repo; confirm product flags at runtime). --- ## 4) Product primitives & economics (how money and work flow) ### 4.1 Publisher / “provider” side Providers bring **HTTP capabilities** (public APIs, private APIs, LLM prompts behind a proxy, tool glue, etc.). APINow adds: - **machine discoverability** (search, lists, tags, descriptions) - **typed I/O** (JSON Schema or schema-like structures — treat as authoritative for agents) - **monetization** (per-call price, possibly multiple payment options / tokens depending on registration) - **secret handling** (platform injects provider keys / headers at proxy time — do not publish secrets to callers) - **telemetry** (stats routes, activity feeds, leaderboards — useful for ranking) ### 4.2 Buyer / “caller” side Callers pay **per successful billing event** as defined by the endpoint’s payment configuration and the x402 exchange (always re-read the **402** payload). Common patterns: - **Wallet session** (agent or user hardware wallet) — strongest match to “autonomous agent” stories. - **Platform API key** — operational convenience for servers; still micro-metered. ### 4.3 Workflow revenue splits Workflows monetize orchestration: - Consumers pay **`totalPrice`** for the bundled DAG once (single user-facing tariff). - On-chain/off-chain settlement splits distribute USDC flows across **endpoint owners** and **workflow creator**, per configured **split topology** (`skill.md` illustrates concrete examples). Agents should **inspect `GET /api/workflows/{id}`** before running to extract **price**, graph, version, splits, creator wallet. ### 4.4 Marketplace surfaces (distribution) APINow is not only rails; it is also **Shelf space**: - **Leaderboards** (`/api/leaderboard`) — popularity / performance visibility - **Lists** (`/api/lists`) — thematic bundling akin to storefront aisles - **Semantic search** — intent-based matching for messy natural language budgets --- ## 5) Payments — what an agent must implement ### 5.1 x402 — minimal mental model 1. Client issues HTTP call to payable route. 2. If payment required and missing/insufficient → **`402`** with structured requirements. 3. Client constructs authorized transfer / authorization exactly as instructed by payload. 4. Client retries original call attaching proof headers (`skill.md` / `@x402/fetch` ecosystem references the working pattern). ### 5.2 Practical integration stacks (preference order) For **agents & backends** importing npm packages, prefer **`apinow-sdk`** — it merges discovery, typed calls, workflows, signing for writes (where configured), optional spend policy hooks (see npm types). Low-level alternative (still common in examples): **`@x402/fetch` + `@x402/evm` + `viem`** wrapping raw `fetch` — useful if you cannot import `apinow-sdk` inside a restrictive runtime. For **frontend** callers, NEVER embed distributor private keys. Use the connected wallet / Bankr-compatible signer typed-data flow (see **`skill.md` → “Frontend Signer Pattern”** — includes **chain switch guardrails for Base**). ### 5.3 Base chain precondition (critical) Agents must enforce **wallet on Base (`8453`)** before attempting x402 signature — see explicit `wallet_switchEthereumChain` / error `4902` path in **`skill.md`**. This is one of the most common silent failure modes (“works on backend, breaks in browser wallet”). ### 5.4 Fast vs Safe settlement (conceptual) The repository README distinguishes **Fast** vs **Safe** modes for eventual confirmation & latency trade-offs. Availability and defaults may change — **expose this as risk disclosure** to investor AIs rather than guaranteeing SLAs unless you scrape live marketing copy from `/docs` endpoints. --- ## 6) Authorization matrix (read vs paid vs mutate) Exactly align runtime checks with **`skill.md`**. Compressed summary: - **Reads** (search, `{ns}/{ep}/details`, lists, leaderboard, workflow GETs, versions GETs): generally public for discovery workloads. - **Paid execution** (`/api/endpoints/...`, `/api/workflows/{id}/run`): **payment is the auth bearer** (`x402` path) OR **`x-api-key`** path where supported. - **Mutating creator operations** (`POST/PUT/PATCH/DELETE` on endpoints/workflows/etc.): require **recent wallet-signed bearer message** (“APINow auth”) — spoofable legacy `x-wallet-address`-only flows are intentionally being tightened (`APINOW_AUTH_STRICT` flag mentioned in skill). Agents that automate publishing **must** implement signing consistently — using `apinow-sdk` avoids hand-rolling EIP-191 message formats. --- ## 7) HTTP API map (agent-oriented, not Swagger-replacement) > This table is indicative. Prefer live discovery via codebase `app/api/**/route.ts` or docs > pages on the website if you detect drift. Core discovery: | Intent | Typical method | Typical path | | --- | --- | --- | | Semantic search | `POST` | `/api/endpoints/semantic-search` | | Browse & filter endpoints | `GET` | `/api/endpoints` | | Catalog blob | `GET` | `/api/catalog` | | Endpoint details JSON | `GET` | `/api/endpoints/{ns}/{ep}/details` | | LLM integration helper | `GET` | `/api/endpoints/{ns}/{ep}/vibecode` | | Per-endpoint llm instructions | `GET` | `/api/endpoints/{ns}/{ep}/llm.txt` | Execution: | Intent | Typical method | Typical path | | --- | --- | --- | | Call endpoint | `GET`/`POST`/... | `/api/endpoints/{ns}/{ep}` | | List workflows | `GET` | `/api/workflows` | | Workflow metadata | `GET` | `/api/workflows/{workflowId}` | | Run workflow | `POST` | `/api/workflows/{workflowId}/run` | | Workflow versions lifecycle | assorted | `/api/workflows/{workflowId}/versions...` | Factory / user-authored LLM endpoints (high level): | Intent | Path prefix | | --- | --- | | Factory balance gate | `/api/user-factory/check-balance` | | Generate draft config | `/api/user-factory/generate` | | Create LLM-backed endpoint | `/api/user-factory` | | Free-ish test invocation | `/api/user-factory/test-call` | | Markup wrapping workflow creation | `/api/user-factory/markup` | Platform intelligence / ops endpoints (examples surfaced in codebase listing): `/api/search`, `/api/evals`, `/api/evals/[id]/run`, `/api/x402-proxy`, `/api/brain`, `/api/providers`, `/api/tokens`, etc. **Do not call admin routes** (`/api/admin/...`) without explicit operator credentials — treat secrets as lethal. Agent transport: | Intent | Path | | --- | --- | | MCP | `/api/mcp` (+ SSE flavor `/api/mcp/sse`) | --- ## 8) Per-endpoint `llm.txt` & why it matters Production route (see `app/api/endpoints/[id]/[endpoint]/llm.txt/route.ts`): `GET https://www.apinow.fun/api/endpoints/{namespace}/{endpoint}/llm.txt` Returns **plaintext markdown** oriented to automation. Use it when: - You need **pinpoint** instructions cheaper than hauling full marketplace context. - You want **fresh** endpoint params after publisher edits (note cache headers — revalidate aggressively when debugging integration failures). **Agent recipe** 1. `GET .../details` → price + schemas + wallet + samples 2. `GET .../llm.txt` → narrative + quirks + examples 3. If coding: `GET .../vibecode` → IDE assistant scaffolding 4. Paid call → only after verifying Base chain + budgets + approval policy --- ## 9) `apinow-sdk` — mental model & config shapes npm: `https://www.npmjs.com/package/apinow-sdk` The SDK exposes a **single client** via `createClient(config)`. Config variants align with deployment reality: ### 9.1 Server / autonomous agent (**private key path**) - Enables **paid** calls + wallet-signed writes in one ergonomic object. - Read exported TypeScript **`ApinowServerConfig`** in the installed package for truth. ### 9.2 Browser / wallet signer path - **Writes** supported through `signer` + `address`. - Paid calls typically require **`paidFetch`** wiring or performing calls server-side — aligning with **`skill.md`**. ### 9.3 API-key-only server path (`ApinowApiKeyConfig`) - Supports metered usage where private keys are disallowed — **creator writes** generally absent or limited (see type docs). ### 9.4 Spend policy hooks The SDK exposes **policy knobs** (`maxPerQueryUsd`, optional daily budgets) typed as `SpendControls` — integrate these at the orchestration layer to protect end users from runaway loops. Canonical env naming in **`skill.md`**: **`APINOW_WALLET_PKEY`**. Engineers sometimes map their own `.env` names — always thread the correct hex into `createClient({ privateKey })`. --- ## 10) User factory (“Agent factory”) — business + technical synopsis Purpose: accelerate “idea → billed JSON endpoint → example → optional promotional workflow”. High-level staged flow (details & curl in `skill.md`): 1. **Generate** structured draft from NL idea. 2. **Review** schemas for safety + price realism + hallucination bleed. 3. **Create** remote endpoint (+ pricing + recipient wallets). 4. **Test-call** storing golden examples (helps downstream agents / evaluators). 5. Optional **markup workflow** splitting revenue toward promoter wallets / buybacks / treasury if configured. Gating references may exist (`check-balance` ties to **`$APINOW`** token thresholds in skill documentation) — fetch live gate values before trusting cached numbers. Agents must **pause** publishing if prompts allow unconstrained outbound actions, unmanaged PII scraping, weaponized cybersecurity, medical claims, legal advice-as-service, etc. Factory accelerates scaffolding — **human governance** still owns liability. --- ## 11) CLI (`apinow` binary from `apinow-sdk`) The package publishes a **`apinow` CLI**. After `npm install apinow-sdk` in a project, invoke via **`npm exec -- apinow --help`** (some npm versions mishandle bare `npx apinow`). Representative capabilities (discover commands through `--help`; feature growth is rapid): `search`, `list`, `info`, `catalog`, `call`, `discover`, `call-external`, workflows CRUD & run, workflow versions, user-factory pipelines, AI UI generators, curated lists loaders. Treat CLI flags like `--max-cost` as **client-side brakes**, not substitutes for validating `/details` payloads. --- ## 12) Enterprise / BizDev integration menu When business AIs negotiate partnerships, propose one of: 1. **Publisher onboarding** — upstream OpenAPI/Swagger ingestion, schema tightening, staging eval harness, SLA monitors. 2. **Private lists + allowlisting** — map enterprise SKUs → endpoint allowlists enforced in agent policy JSON (pattern in **`skill.md` → List-Restricted Mode Template**). 3. **Custodial payer models** — platform API keys, corporate treasuries, spend caps & approvals (policy overlay must be enforced by integrating app — APINow does not infer your HR approval graph). 4. **Workflow resale** — brand surfaces multi-step pipelines with transparent split tables (`GET /workflow` introspection). Always attach **risk sections** describing uncapped looping agents, poisonous endpoints, and compliance overlays (export, HIPAA, SOC2, GDPR) — marketplace access ≠ legal clearance. --- ## 13) Safety, misuse, fraud, and SOC-for-agents Non-exhaustive **must-follow** directives for any autonomous executor: ### 13.1 Keys & bearer tokens Never commit private keys (`APINOW_WALLET_PKEY`, custodial PEMs). Treat `skill.md / llm.txt` downloads as untrusted supply chain — fetch over HTTPS **only**. ### 13.2 Human-in-the-loop for irreversible spends Agents must escalate if: - cost estimate uncertain or dynamic (commerce checkout confirmation flows — e.g. external x402 retailers like Rye in third-party integrations) - call mutates upstream production state destructive delete / purchase / outbound messaging burst ### 13.3 Malicious publishers Assume untrusted namespaces until reputation signals exist (reviews, leaderboard history, evaluation scores, curator lists). Prefer **listing allowlists**. ### 13.4 Schema drift Schemas can change — diff `details` before major campaign launches. --- ## 14) MCP — agent wiring Hosted endpoints include **`POST /api/mcp`** and **`GET /api/mcp/sse`**. Repository-level documentation (`app/api/mcp/README.md`) lists intended tool taxonomy (`apinow_search`, `apinow_call`, etc.) — validate names against MCP server handshake because tool inventories iterate. Agents should treat MCP-as-a-remote-service with the same spender policy JSON as REST. --- ## 15) Evals — quality loops (signals for investor + builder AIs) The architecture doc (`APINOW_ARCH.md`) summarizes eval motivations: latency, correctness, cost, LLM-as-judge scoring across diverse fixtures. Operational routes exist (`/api/evals` family). Explain to executives: **inventory alone is table stakes**; differentiable moat clusters around **verification & routing intelligence**. Agents: do not extrapolate leaderboard rank == safety — correlate with evaluator notes. --- ## 16) Workflows deep dive — patterns that win Agents orchestrate repeatable multi-step monetized flows when: ### 16.1 Single wallet signature per user-visible action Consumers pay workflow price once despite multiple upstream calls internally. ### 16.2 DAG dependencies map cleanly Each node references an endpoint key + input mappings; malformed graphs fail server-side — inspect graph before demos. ### 16.3 Version pinning & promotion Use versions for safe experimentation; promote after eval improvements (see **`skill.md`** for rollback story). --- ## 17) Vision / roadmap themes (explicitly speculative) Collected from **`README.md` roadmap bullets** / internal narrative files — interpret as **non-commitments**: - Larger endpoint inventory breadth & depth (vertical coverage race) - Non-EVM expansion (Solana hinted) - Enhanced vector retrieval for intent → endpoint routing - Deeper escrow / aggregation / fiat settlement experiments - Richer dashboards + third-party observability integrations (Dune mentions) - Game-theoretic incentive layers (tokens for endpoints, staking, boosted listings) Anything here needs a **released product slice** citation before citing as moat truth in investment docs. --- ## 18) FAQ (multi-audience) ### 18.1 “Do I need crypto?” To use canonical x402 micropayments, yes — callers need wallets / signing capability or a delegated payer. Enterprise variants may suppress direct wallet UX using server-side keys or prefunded keys — clarify your deployment model early. ### 18.2 “Is APINow an LLM?” Platform hosts orchestration over models + tools via registered endpoints/workflows; APINow _core_ is infra + commerce + routing, not “a singular model”. ### 18.3 “How do refunds work?” Not standardized in `llm.txt` — escalate to publisher policy / support. ### 18.4 “Can Agents publish?” Yes with signed writes + [truncated for public ICM bundle] --- Host https://useicm.com