Analysis

[NalinDalal]

Competitive Analysis: Self-Maintaining APIs

Last updated: September 2026
Status: Active research — we reviewed these projects silently to avoid repeating their mistakes and to understand the landscape before building.

---

Why this exists

The "self-maintaining APIs" concept is gaining traction. YC published an RFS for it. Multiple teams are building solutions. We tracked their development quietly to:

1. Understand what approaches work and what don't
2. Avoid architectural mistakes others have made
3. Identify gaps we can fill
4. Reference their work transparently

This is not a threat analysis — it's market intelligence.

---

The landscape

Project	Stage	Approach	Language	LLM	Traction
DriftLock (us)	Active development	Static analysis + sandbox snapshots + diff	TypeScript/Bun	OpenAI	Building
Ripple (Aakash2408)	Demo stage	Spec diff + consumer finding + fix gen	Go (inferred)	Claude	0 stars, private core
HelpPR (pedapudi-pavansai)	Most mature	OpenAPI monitoring + static analysis + LLM	Python + React	Claude	0 stars, 28 commits
banningwill-AdAstra	Prototype	AST visitor + fix gen	Python	Claude	0 stars, 2 commits
RajaDheeraj	Prototype	Agent-based (regex + LLM)	Python + React	Gemini	0 stars, 3 commits
Ability.ai	Platform play	Agent runtime + knowledge graph	N/A	Multi-model	544 stars (Trinity)

---

Detailed analysis

1. Ripple (Aakash2408)

GitHub: https://github.com/Aakash2408/ripple (private core)
Demo repos: https://github.com/Aakash2408/ripple-demo-api, https://github.com/Aakash2408/ripple-demo-frontend, https://github.com/Aakash2408/ripple-payments-api, https://github.com/Aakash2408/ripple-sdk-node, https://github.com/Aakash2408/ripple-sdk-java, https://github.com/Aakash2408/ripple-sdk-python

What they built:

• Core engine (Go, private) that diffs old vs new API specs
• 10 diff engines (OpenAPI, Protobuf, GraphQL, DB/Prisma, AsyncAPI, Avro, tRPC, Thrift, JSON Schema, Smithy)
• 5-strategy consumer finder (grep, import graph, git co-change history, playbooks, multi-invoker)
• Template-based + LLM (Claude) fix generation
• GitHub App + GitHub Action + Docker self-hosted agent

What we learned from them:

• The git co-change history strategy is clever — if two files always change together in commits, they're likely coupled. We should consider this.
• Their ensemble consumer-finding approach (5 strategies) is more robust than single-strategy detection
• Supporting 10 contract types is ambitious but unverified — all demos only show OpenAPI
• The PropBench benchmark (268 scenarios) is self-created — no independent validation

Gaps we identified:

• Core source code is private — no independent audit possible
• All demo repos are trivial (1-2 files, 2-5KB each)
• No auto-generated PRs have been merged — all remain open
• Solo founder, no team
• No production validation or case studies
• Landing page returns 404

Our takeaway: Their architecture is interesting but unproven at scale. We should focus on production-ready tooling rather than demo-stage breadth.

---

2. HelpPR (pedapudi-pavansai)

GitHub: https://github.com/pedapudi-pavansai/HelpPR

What they built:

• Full platform: React frontend + FastAPI backend + MongoDB
• OpenAPI spec monitoring and breaking change detection
• Deterministic static analysis + bounded LLM reasoning (Claude)
• AWS ECS Fargate deployment with Terraform
• GitHub App integration

What we learned from them:

• Their deterministic-first, LLM-second approach is smart — scan mechanically first, only use AI for ambiguous cases
• The backend module structure (detector, diff, languages, llm, patcher, pipeline, scanner, watcher) is well-organized
• Using MongoDB for persistence makes sense for their scale
• The watcher module for upstream API monitoring is a feature we haven't built yet

Gaps we identified:

• Multi-language support is listed as "future improvement" — not built yet
• AST-based code transformations not implemented
• No evidence of production use
• Most complex architecture — higher barrier to entry
• 0 stars, no community adoption

Our takeaway: Their deterministic-first approach validates our static analysis strategy. We should consider adding an upstream API watcher.

---

3. banningwill-AdAstra/self-maintaining-apis

GitHub: https://github.com/banningwill-AdAstra/self-maintaining-apis

What they built:

• Python AST visitor that detects deprecated OpenAI SDK patterns
• Claude-powered fix generation
• GitHub Actions integration (push + weekly schedule)
• 4 detection rules for OpenAI SDK deprecations

What we learned from them:

• AST-based detection is more accurate than regex — it understands code structure
• Running scans on a weekly schedule (even without code changes) catches upstream deprecations
• The three modes (detect, detect+diff, detect+apply) give users control

Gaps we identified:

• Python-only detection
• Only 4 OpenAI SDK rules implemented
• No validation of LLM-generated fixes
• Very early stage (2 commits)

Our takeaway: AST-based detection is worth considering for higher accuracy. Weekly scheduled scans are a feature we should add.

---

4. RajaDheeraj/self-maintaining-apis

GitHub: https://github.com/RajaDheeraj/self-maintaining-apis

What they built:

• FastAPI + React agent-based system
• Google Gemini function-calling for autonomous code search and fix
• Strict fix validation (revert + diff check)
• Single hardcoded migration pattern (get_user → retrieve_user)

What we learned from them:

• Their strict validation approach (revert the edit, diff against original) ensures fixes don't introduce new bugs
• The agent-based architecture (LLM autonomously searches, reads, proposes) is ambitious but risky

Gaps we identified:

• Hardcoded to a single migration pattern
• Python-only
• No CI/CD integration
• 12-second rate-limit sleeps (Gemini free tier)
• 3 commits, 0 stars

Our takeaway: Strict fix validation is a good idea. Agent-based approaches are too unpredictable for production use.

---

5. Ability.ai

Website: https://www.ability.ai
Article: https://www.ability.ai/blog/self-maintaining-apis-downtime

What they built:

• Trinity: Open-source (Apache 2.0) AI agent runtime platform
• Cornelius: Self-improving cognitive core (knowledge graph)
• Self-maintaining APIs as a use case on their platform

What we learned from them:

• The 30% downtime stat they cite is the same one in our YC application — it's becoming the standard pitch
• Their open-core model (open source + enterprise features) is a proven business model
• The MCP integration (90+ tools) and channel integrations (Slack, WhatsApp) represent substantial platform work

Gaps we identified:

• Self-maintaining APIs appears to be a vision/roadmap item, not a shipped product
• No published pricing
• SOC 2 still "in progress"
• 544 stars suggests early traction

Our takeaway: They're a platform play, not a direct competitor. Their article validates the problem space.

---

Common patterns across all projects

1. Everyone cites the 30% downtime stat — it's becoming the standard pitch for this space
2. No project has meaningful traction — all have 0 stars (except Ability.ai's platform)
3. Python dominates — most competitors are Python-based
4. LLM-powered fixes are universal — everyone uses Claude or Gemini for complex fixes
5. Deterministic detection first — the better projects scan mechanically before using AI
6. No production validation — nobody has case studies or real users yet

---

What we do differently

Dimension	Competitors	DriftLock
Language	Mostly Python	TypeScript/Bun (faster, type-safe)
Detection	Spec diffing or regex	Static analysis + sandbox snapshots
Fix validation	Some (RajaDheeraj)	Built-in (snapshot diffing)
Test classification	None	Monitored/blind/untested
Persistence	In-memory or MongoDB	PostgreSQL + Drizzle ORM
Architecture	Monolithic or agent-based	Modular monorepo
Approach	Vendor provides specs	We infer from code + sandbox

---

Gaps we can fill

1. Test classification — nobody else distinguishes mocked vs real tests
2. Sandbox snapshots — nobody captures actual request/response shapes from test runs
3. TypeScript/Bun — faster development cycle, better type safety
4. Production-ready — modular architecture, proper database, CI/CD from day one
5. Vendor-agnostic — we don't need vendors to publish specs

---

What we should consider adopting

1. Git co-change history (from Ripple) — detect coupled files
2. AST-based detection (from banningwill-AdAstra) — more accurate than regex
3. Weekly scheduled scans (from banningwill-AdAstra) — catch upstream deprecations
4. Strict fix validation (from RajaDheeraj) — ensure fixes don't introduce bugs
5. Deterministic-first approach (from HelpPR) — scan mechanically, use AI only for ambiguous cases

---

References

• Ripple
• Ripple demo repos: demo-api, fe, payment, node-sdk, java-sdk, python-sdk
• HelpPR
• banningwill-AdAstra
• RajaDheeraj
• Ability.ai
• YC RFS

[NalinDalal]

Product Engineering

Core detection loop

GitHub App install → discover call sites → classify tests →
probe sandbox → diff specs → open PR → report coverage

The engineering challenge is making each arrow reliable enough that a design partner trusts it in week one.

What makes it hard (and interesting):

1. Knowing what actually changed — not just "Stripe updated" but "field X was renamed to Y in this specific endpoint." You need to map a vendor-level change onto a specific call site in a specific language/SDK.
2. Knowing who it affects — only repos that call that specific endpoint with that specific field. You can't blast every Stripe customer with every drift; you need per-repo, per-call-site targeting.
3. Suggesting the right fix — not just "something changed" but "replace charge.amount with charge.value on line 42." This is the difference between a useful bot and noise.

Every other section in this doc is a sub-problem of one of these three.

---

1. Static usage extraction

Goal: find every call site that touches Stripe, extract the endpoint, params sent, and response fields accessed.

Approach for Stripe (v1)

Stripe's Node SDK (stripe.*) is a thin wrapper. The actual HTTP surface is:

// Pattern 1: direct SDK call
const charge = await stripe.charges.create({ amount: 1000, currency: 'usd' });
console.log(charge.status);

// Pattern 2: via resource access
const customer = await stripe.customers.retrieve('cus_123');

// Pattern 3: list/search
const invoices = await stripe.invoices.list({ customer: 'cus_123', limit: 10 });

For v1, we target the Node.js SDK only. Extraction strategy:

1. AST parse — use @babel/parser or tree-sitter to find MemberExpression chains where the root is an identifier named stripe (or destructured aliases like const { charges } = stripe).
2. Argument inference — extract the literal/object passed as the first argument. This gives us the request shape the code expects to send.
3. Response field tracking — find property accesses on the returned value. charge.status, invoice.lines.data[0].amount, etc.

Output format per call site

{
  "file": "src/services/billing.ts",
  "line": 42,
  "method": "stripe.charges.create",
  "endpoint": "/v1/charges",
  "requestShape": { "amount": "number", "currency": "string", "customer": "string?" },
  "responseFields": ["status", "id", "amount", "currency"],
  "testFiles": ["src/services/billing.test.ts"]
}

Known limitations

• Destructured aliases (const s = stripe) require scope analysis. Fall back to file-level regex for aliases we can't resolve.
• Dynamic SDK methods (stripe[methodName](...)) can't be statically resolved. Skip with a warning.
• Wrapper abstractions (billingService.createCharge(...)) that internally call Stripe will be missed unless we trace through the wrapper. Accept this coverage gap in v1.

---

2. Test classification (mock vs. sandbox)

Goal: know which tests actually hit Stripe's test-mode API vs. mock the HTTP layer.

Detection signals (ranked by reliability)

Signal	Reliable?	How to detect
jest.mock('stripe') or vi.mock('stripe')	High	Parse test file for mock declarations
MSW/nock interceptors registered	High	Check for msw, nock, fetch-mock setup in test file
stripe.setApiKey('sk_test_...') present	Medium	Means real credentials are configured, but doesn't prove the test runs un-mocked
No mock signal + test command runs	High (empirical)	Run the test suite with a network proxy; if no traffic to api.stripe.com exits, it's blind

v1 heuristic (good enough)

Combine signals:

1. If any mock library is detected in the test file → tested-but-blind.
2. If the test command, run with our proxy, produces zero traffic to api.stripe.com → untested (or all tests in the suite are mocked).
3. Otherwise → monitored.

The proxy trick

To empirically detect sandbox traffic, run the test command with:

HTTPS_PROXY=http://localhost:8888 npm test

Our lightweight Node proxy records all outbound HTTPS traffic. After the test run:

• Traffic to api.stripe.com with Authorization: Bearer sk_test_... → monitored.
• No traffic → blind or mocked.

This is more reliable than static mock detection alone, because it catches:

• Tests that mock at the fetch level (not stripe module level)
• Tests that use environment-based flagging to skip external calls
• Test files that import a shared mock setup

---

3. Sandbox probing

Goal: run the customer's test suite (or a probe command they nominate) against their sandbox credentials and capture request/response shapes.

How it works

1. Customer nominates a command: e.g., npm run test:integration or npm test -- --grep "stripe"
2. We run it in a fresh CI job with:
   • Their repo checked out
   • Their env vars (STRIPE_SECRET_KEY=sk_test_..., etc.) injected from their GitHub Secrets
   • HTTPS_PROXY pointing to our local recorder
3. The proxy logs every request/response pair keyed by the test file + line number (or call site if we can instrument the SDK).

Safety: non-idempotent endpoints

Stripe's POST endpoints (charges, customers, invoices) have real side effects even in test mode — they consume test data, can hit limits, and may trigger webhooks.

v1 policy:

• Only probe GET endpoints by default (retrieve, list, retrieve-upcoming-invoice).
• POST/PUT/DELETE endpoints are classified as "non-idempotent" and skipped unless:
  • The test explicitly uses Stripe test mode (sk_test_* key), and
  • The test suite has a documented "safe to replay" flag or the customer explicitly whitelists the endpoint in a config file we provide.

Credential handling

• Never persist raw API keys. Pull from GitHub Secrets at job runtime.
• Rotate/expire keys are the customer's responsibility.
• We only need read-level access for GET probes; write access is only needed if the customer explicitly opts into POST probing.

---

4. Schema diffing

Goal: compare two snapshots of the same endpoint's request/response shape and classify changes.

What we diff

Layer	What we track
Request	Param names, types, required vs. optional
Response	Top-level fields, nested objects, array element shapes, status codes
Both	Added fields, removed fields, type changes (string → number), optionality changes

Diff algorithm

Use JSON Schema as the intermediate representation:

1. Infer a JSON Schema from each snapshot (use a library like json-schema-generator or hand-roll for Stripe's known shapes).
2. Diff the two schemas using a structural diff (not line-by-line).
3. Classify each diff as:
   • BREAKING: field removed, field type changed, field became required, status code added/removed
   • NON-BREAKING: field added as optional, enum expanded
   • UNKNOWN: ambiguous change (e.g., array element shape changed but we only saw one element)

False positive mitigation

• Require the same field to change in N consecutive snapshots before flagging (configurable, default 2).
• For TypeScript codebases, cross-reference against the codebase's type definitions: if the code already uses the new shape, it's a false positive (the developer already adapted).
• Whitelist known-safe Stripe deprecations (e.g., source → payment_method migration that Stripe announced and documented).

---

5. PR generation

Goal: produce a PR that a human can review and merge in under 2 minutes.

PR structure

Title: [Driftlock] Stripe API drift detected: charge.status changed from string to nullable string

Body:
## What changed
Stripe changed the `status` field on `POST /v1/charges` responses.
- Before: `string` (e.g., "succeeded", "failed")
- After: `string | null`

## Where you use it
src/services/billing.ts:42 — `const charge = await stripe.charges.create(...)`
src/services/billing.ts:45 — `console.log(charge.status)`

## Suggested fix
Add a null check before using `charge.status`:

\`\`\`diff
- console.log(charge.status)
+ console.log(charge.status ?? 'unknown')
\`\`\`

## Coverage note
This endpoint is monitored (test: src/services/billing.test.ts, hits Stripe test mode).

Fix generation strategy

For v1 Stripe, build a small fix template library keyed by diff pattern:

Diff pattern	Suggested fix template
field removed	Remove access, or use ?. optional chaining
field type widened (e.g., string → string | null)	Add null coalescing (??) or explicit null check
field type narrowed (e.g., string → enum)	Add switch/guard for new enum values
new required request param	Add param with sensible default or mark as required in your input type
status code added	Add new case to error handling switch

This is Stripe-specific. Generalizing to N vendors is post-v1 work.

Branch hygiene

• Branch name: driftlock/{call-site-hash}-{timestamp}
• Delete immediately after PR is merged or closed (webhook listener on pull_request events).
• One PR per drift event, not batched.

---

6. Infrastructure

Stack recommendation

Layer	Choice	Reason
Webhook server (apps/webhook)	Bun native server	Owns /webhooks/*, /auth/*, and the dashboard JSON API in one process on :3001
Dashboard (apps/fe)	React + Vite + TanStack Router	Client usage only; calls the webhook JSON API, no server-side logic
Background workers	Inngest or BullMQ + Redis	Event-driven, handles webhook retries and scheduled probe runs
Database	PostgreSQL	Call sites, snapshots, drift events, installations
Proxy (sandbox probing)	Custom Node HTTP(S) proxy	Lightweight, single-purpose
Queue for probe jobs	Same as workers	One queue, multiple consumers
Hosting	Vercel (dashboard) + Fly/Render (webhook server, workers, proxy)	Separate the stateless dashboard from the stateful server

Data retention

• Snapshots: keep last 2 per call site (current + previous). Older snapshots are cold and can be archived.
• Drift events: keep indefinitely (audit trail).
• Coverage reports: regenerate on demand from current snapshot + test classification state.

Cost model for running a probe

A typical probe job:

• Clones the repo: ~30s, ~100MB bandwidth
• Installs deps: ~60s, cached between runs
• Runs tests: 30s–5min (customer's existing suite, we don't add significant overhead)
• Proxy overhead: negligible

Aim for <5 min total for a probe job. If the customer's full suite is slow, let them nominate a subset (e.g., npm test -- --grep "stripe").

---

7. v1 implementation priority

Build in this order:

1. GitHub App skeleton — install webhook, repo read access, PR creation. Prove the OAuth + permission flow.
2. Stripe static extractor — AST parse for stripe.* calls. Output call sites. Run against 3–5 real open-source repos and measure precision/recall.
3. Probe proxy — Node HTTPS proxy that records request/response pairs. Run a customer's Stripe test suite through it end-to-end.
4. Snapshot storage — persist captured shapes. Build the "previous vs. current" diff UI.
5. Diff classifier — JSON Schema diff with breaking/non-breaking classification.
6. PR generator — template-based fix suggestions for Stripe-specific diff patterns.
7. Coverage reporter — per-call-site status, surfaced in PR comment or status check.
8. Scheduler — cron-like re-probing. Start with manual trigger, then add scheduled runs.

---

8. What to instrument from day one

Logging that will save you weeks of debugging:

• Every call site discovered (file, line, method, inferred endpoint)
• Every probe run: command, duration, exit code, traffic captured count
• Every drift event: diff summary, confidence score, whether a PR was opened
• PR lifecycle: opened → merged/closed, time-to-merge, time-to-close
• False positive signals: PR opened but customer comments "not a real issue"

This data is also your YC demo gold — "we detected 12 drifts across 8 design partners, 10 of which were real, here's the PRs."

[NalinDalal]

Progress Update — September 2026

Since the competitive analysis, we've shipped a working MVP:

What we built:

• Webhook capture (Stripe, Twilio, generic)
• Schema drift detection (added/removed/type changed)
• Auto PR creation with code fixes
• GitHub OAuth login + GitHub App installation
• Settings dashboard (DB-backed config)
• Rollback detection

How we compare to competitors:

Feature	Us	Ripple	HelpPR
Working demo	✅	❌ (private core)	❌ (no evidence)
Auto PR creation	✅	⚠️ (open, not merged)	❌
Multi-vendor	❌ (Stripe only)	✅ (10 diff engines)	❌
Production ready	⚠️ (local dev)	❌	❌
Test classification	❌ (planned)	❌	❌
AST-based detection	❌ (planned)	❌	❌

Key insight: Most competitors are at demo/prototype stage. We're the only ones with a working end-to-end flow (webhook → drift → PR).

Next priorities:

1. Parser (AST-based code analysis)
2. AI Agent (actual code fixes, not just TODOs)
3. Test classification (mock vs real)