api-anything

Turn any app into a programmable API. Point an agent at an app, let it observe how the app talks to its own backend, and get back a typed client and an MCP server that any agent can drive.

Most apps you want to automate — LinkedIn, your bank, an internal tool, a SaaS with no public API — already have an API. It's the private one their own frontend uses. This framework gives an agent the structure, tools, and output format to reverse-engineer that private API and hand you back something programmable.

   the app            capture method              IR                 output
┌────────────┐   ┌────────────────────┐   ┌──────────────┐   ┌──────────────────┐
│  LinkedIn  │   │ network-capture     │   │              │   │  typed client    │
│  your bank │──▶│ graphql-introspect  │──▶│   ApiSpec    │──▶│  MCP server      │
│  any SaaS  │   │ openapi-import      │   │  (one shape) │   │  live executor   │
│  ...       │   │ bundle-analysis     │   │              │   │                  │
└────────────┘   │ browser-automation  │   └──────────────┘   └──────────────────┘
                 └────────────────────┘

The idea in one line

The agent is the reverse-engineering engine. The framework gives it (1) one normalized representation to fill in — the ApiSpec — (2) pluggable capture methods that produce that representation from different kinds of evidence, (3) one deterministic runtime and codegen that turn any filled ApiSpec into a working client + MCP server, and (4) a playbook that drives the loop.

That's the whole design: N capture methods → 1 IR → 1 runtime. Adding a new way to reverse-engineer an app means writing a function that emits an ApiSpec; everything downstream — validation, the typed client, the MCP server, the live executor — comes for free.

Zero friction: point your agent at it

The whole point is that a person shouldn't have to think about any of the below. They point their coding agent (Claude Code, etc.) at this repo and say:

"I want Instagram as an API."

The agent loads the skill and does the rest: it surveys the app's whole feature surface first (view/search/filter posts, profiles, feed, comment, repost, follow, DMs…), writes that down as a feature map, then builds an operation per feature — core capabilities first — and hands back an MCP server + CLI + typed client + docs for the app. Not a two-endpoint demo: a mapped, documented API that covers what people actually do in the app.

That "map the features first, then build to cover them" discipline is FEATURE-MAPPING.md, and coverage is tracked:

api-anything features x.apispec.json --map x.features.json
# X (Twitter) — 4/25 features built (16%); backlog: read-user-posts, home-timeline, like-post, repost, follow-user …

Capture methods

An agent picks whichever fits the target (see method-selection.md):

| Method | Use when | Produces | | --- | --- | --- | | network-capture | Modern SPA making XHR/fetch/GraphQL calls you can observe | ApiSpec from a HAR | | graphql-introspect | A GraphQL endpoint with introspection enabled | ApiSpec from the schema | | openapi-import | The app already ships an OpenAPI/Swagger doc | ApiSpec from the spec | | bundle-analysis | You need to discover hidden endpoints / persisted-query ids in the JS | Findings to guide capture | | browser-automation | No usable HTTP API, or heavy anti-automation | A Playwright recipe |

Methods compose: scan the bundle to find the endpoints, capture the live traffic to fill in the shapes, introspect the GraphQL for types.

Quickstart

The installed CLI consumes an ApiSpec file. This minimal example is completely self-contained:

cat > acme.apispec.json <<'JSON'
{
  "name": "acme",
  "displayName": "Acme",
  "version": "1.0.0",
  "baseUrl": "https://api.example.com",
  "auth": { "type": "none" },
  "operations": [{
    "name": "status",
    "summary": "Read service status",
    "readOnly": true,
    "request": { "method": "GET", "pathTemplate": "/status" }
  }]
}
JSON
npx -y @sift-wiki/api-anything validate acme.apispec.json
npx -y @sift-wiki/api-anything gen acme.apispec.json --out ./out

From a repository checkout, the curated LinkedIn capsule provides a more complete example:

npm install
npm run build

# Inspect the flagship example — LinkedIn, reverse-engineered:
npx @sift-wiki/api-anything validate marketing/linkedin/linkedin.apispec.json

# Generate a typed client + MCP server from any ApiSpec:
npx @sift-wiki/api-anything gen marketing/linkedin/linkedin.apispec.json --out ./out

# Serve it as an MCP server any agent can connect to (reads only by default):
LINKEDIN_COOKIES='li_at=...; JSESSIONID="ajax:..."' \
  npx @sift-wiki/api-anything serve marketing/linkedin/linkedin.apispec.json

# Or call a single operation live (great for validating a fresh capture):
npx @sift-wiki/api-anything call marketing/linkedin/linkedin.apispec.json getMe

Reverse-engineer a new app

# 1. Observe the app (browse it with network recording on) and save a HAR.
# 2. Turn the HAR into a first-draft ApiSpec:
npx @sift-wiki/api-anything from-har capture.har --name acme --base https://app.acme.com --out acme.apispec.json

# 3. Refine the draft (name operations, set auth, mark writes), then verify:
npx @sift-wiki/api-anything call acme.apispec.json listProjects --dry     # inspect the request
npx @sift-wiki/api-anything call acme.apispec.json listProjects           # real read

# 4. Generate + serve:
npx @sift-wiki/api-anything gen acme.apispec.json
npx @sift-wiki/api-anything serve acme.apispec.json

The full loop an agent follows is in agents/PLAYBOOK.md.

The ApiSpec

One JSON document describes an app's API: its base URL, its auth model, and its operations (request shape, params, response extraction, whether it mutates state). It's the contract every method targets and everything downstream consumes. See src/ir.ts for the full schema, and marketing/linkedin/linkedin.apispec.json for a real one.

{
  "name": "linkedin",
  "baseUrl": "https://www.linkedin.com",
  "auth": {
    "type": "cookie",
    "cookies": ["li_at", "JSESSIONID"],
    "csrf": { "header": "csrf-token", "fromCookie": "JSESSIONID", "transform": "strip-quotes" }
  },
  "operations": [
    {
      "name": "getFeed",
      "request": { "method": "GET", "pathTemplate": "/voyager/api/graphql", "query": { "count": "{count}" } },
      "response": { "extract": "data.feedDashMainFeed.elements" }
    }
  ]
}

Why this exists (the bigger picture)

This framework is MIT-licensed and is being prepared for an open-source repository launch. During the private staging phase, the installable npm packages and live catalogue are public while the development fork remains private. The npm tarballs include their TypeScript source, agent guides, and curated capsule examples under the MIT license, so the installable artifacts remain inspectable during staging. Every time someone uses the framework to turn an app into an API, the artifact they produce — the ApiSpec + adapter, a self-contained capsule — is exactly the thing worth sharing. As capsules accumulate, they converge into one unified, agent-facing surface: configure each site's credentials once, and your agent can reach every installed app through a single MCP connection.

We're building the browser for agents. This is the part that reverse-engineers the web into something agents can actually use. See CONTRIBUTING.md for how to add a capsule.

One connection, every installed capsule

The separately packaged @sift-wiki/api-anything-gateway is the agent-facing aggregation layer. It keeps this repository's capture/runtime core reproducible and independently useful, while giving an MCP client one local connection across every capsule you choose to install:

website capture -> declarative ApiSpec -> repository-checked catalogue release
                -> digest-pinned local install -> one MCP gateway -> agent

# Discover and pin a repository-checked capsule from the live catalogue.
npx -y @sift-wiki/api-anything-gateway search "social profile"
npx -y @sift-wiki/api-anything-gateway install linkedin

# Start one stdio MCP server for all installed capsules.
npx -y @sift-wiki/api-anything-gateway

The stable MCP surface is intentionally compact: search_capabilities, describe_capability, and call_operation, plus a bounded deterministic set of common read tools. Remote catalogue entries are searchable but never executable until explicitly installed. Artifact digests are verified before parsing, writes remain denied per capsule unless explicitly enabled, and installed pins are revalidated before use so a newly revoked security release is refused by a long-running gateway rather than silently run.

The live capsule catalogue is a small Cloudflare Worker + R2 service with a dependency-free HTML/CSS/JS frontend. A successful capture job publishes only after named schema, secret-scan, single-capsule MCP, and unified-gateway compatibility checks pass; the site revalidates its authoritative snapshot every 30 seconds. The contracts and rollout decisions live in docs/plans/api-anything-platform/.

The framework improves itself

The capture methods are a starting set, not a ceiling. When an app resists them, the driving agent problem-solves and records what it found in a learning ledger. The package merges its shared seed (agents/learnings.jsonl) with your writable personal ledger at ~/.api-anything/learnings.jsonl — anti-bot tactics, auth quirks, new capture approaches, and documented dead-ends. The next agent reads the ledger during recon, so knowledge compounds instead of being rediscovered:

api-anything learn list --app instagram      # what past runs learned about an app
api-anything learn list --signal "cloudflare" # tactics for a symptom you're hitting
api-anything learn add --title "…" --scope anti-bot --signals "…" --solution "…"

Every hard app ends one of two ways — a new reusable tactic, or a documented dead-end. The ratchet only turns forward. The protocol agents follow is in agents/RECURSIVE-IMPROVEMENT.md.

Authentication & staying fresh

Real apps are authenticated, drift over time, and sometimes make you fetch a token before you can do anything. The framework handles all three:

• Sign-in first. The API worth building is the authenticated one. The driving agent prompts you to log into the app in your browser, then captures the real, logged-in API. api-anything auth <spec> prints the exact cookie steps and confirms your session is live (via the spec's authProbe op). Credentials live in your env, never in the spec.
• Fetch-a-token-first (auth.prepare). Some apps require a pre-request step — mint a guest/CSRF/access token, then use it. Declare it once and the runtime mints, injects, and caches the token automatically. This is what makes X's guest-token reads work end-to-end with zero manual handling (skipIfCookie skips it once you're logged in):

  "auth": { "prepare": [{
    "name": "guestToken",
    "readOnly": true,
    "request": { "method": "POST", "pathTemplate": "https://api.x.com/1.1/guest/activate.json",
                 "headers": { "authorization": "Bearer <public-bundle-bearer>" } },
    "extract": "guest_token", "set": { "in": "header", "name": "x-guest-token" },
    "cacheSeconds": 10800, "skipIfCookie": "auth_token"
  }] }

• Self-healing. Private APIs rotate their internal ids and expire tokens. api-anything verify <spec> health-checks every read op and flags STALE (a staleSignals match) so you know exactly what to re-capture — instead of a silent break.

Use it responsibly

This tool automates apps using your own authenticated session. Use it on accounts you own, respect each app's Terms of Service and robots directives, prefer read operations, and keep destructive operations behind explicit consent (readOnly: false operations are gated by --allow-writes). Credentials live in your environment and are never written into an ApiSpec.

Layout

src/ir.ts            the ApiSpec — the contract everything targets
src/runtime.ts       the executor: ApiSpec + operation + args -> HTTP -> payload
src/auth.ts          credentials + auth application (cookies, CSRF, bearer, api-key)
src/codegen.ts       ApiSpec -> typed client + MCP server source
src/mcp.ts           ApiSpec -> a live MCP server
src/cli.ts           the api-anything CLI
src/methods/         the pluggable capture methods
gateway/             isolated multi-capsule MCP package
registry/            catalogue API, R2 persistence, and static site
agents/              the playbook + skill that drive the framework
marketing/linkedin/  the flagship reverse-engineered example
test/                self-checks

MIT licensed.