Engineering · 11 min
How Elva reads a repo: from route handlers to OpenAPI 3.1Read →API Catalog
Every endpoint you own, including the ones nobody documented
Connect a repo and Elva reads your code, generates the specs you never wrote, groups endpoints into collections, and scores each one. No OpenAPI file required to start.
Spec generation from codeRescan on every commitConsumption dataUnlimited endpoints
API catalogsynced 2m ago
endpoints 214collections 6specs written 83agent-ready 73%
Paymentsv2.4.138 endpointsA · 92%
Identity & Authv1.9.024 endpointsB · 84%
Legacy Billingno spec in repo17 endpointsD · 61%
Ordersv3.0.252 endpointsB · 81%
Internal tooling · Webhooks83 endpoints
83 specs written by Elva, none existed in the repo
214ENDPOINTS FOUND
83SPECS ELVA WROTE
42SECONDS TO FIRST CATALOG
31ORPHANED ENDPOINTS SURFACED
01Discovery
Your code is the source of truth, not a stale spec file
Elva reads routes, handlers, types, and validators straight from the repo. Where a spec exists it is imported and diffed. Where it does not, one is written for you, and it stays accurate because the scan reruns on every commit.
elva scan
❯ elva scan acme/payments-api
▸ Detecting frameworks.............. express, fastapi
▸ Reading routes and handlers....... 1,204 files
▸ Endpoints discovered............ 214
▸ Specs found in repo............. 131 imported
▸ Specs generated from code........ 83 written
▸ Labeling and grouping............ 6 collections
▸ Scoring endpoints............... 73% agent-ready
31 endpoints have no callers anywhere in the repo
4 endpoints expose PII with no auth defined
✓ catalog ready · 42s · rescan armed on every commit
Works without OpenAPIExpress, FastAPI, Spring, Rails, Go, NestJS. Elva infers paths, methods, params, and response shapes from the code, then writes OpenAPI 3.1 you can commit.
Finds what nobody remembersInternal admin routes, debug handlers, forgotten v1 endpoints still serving traffic. They show up in the catalog with an owner and a score, not in an incident.
Many repos, one catalogMicroservices land in one place with consistent naming, so nobody has to guess whether payments lives in two services or five.
02Organization
Grouped, labeled, and searchable in one pass
214 endpoints in a flat list is not a catalog. Elva labels each one by domain, auth requirement, and data sensitivity, then groups them into collections your team already thinks in.
Endpoints214 total
Search endpoints
METHODPATHCOLLECTIONLABELSCONSUMERSSCORE
POST/internal/debug/replayInternal toolingno authinternalnoneF · 22%
GET/billing/legacy/invoicesLegacy Billingspec generatedPII1 serviceD · 54%
GET/ordersOrdersunpaginatedhigh traffic9 callersC · 68%
DELETE/builds/{id}Internal toolingbreaking change2 servicesC · 71%
GET/users/{id}/profileIdentity & AuthPIIOAuth26 callersB · 84%
POST/webhooks/stripeWebhooksno authsignature onlyexternalB · 80%
GET/v1/payments/{id}Paymentsdeprecatedduplicate1 partnerB · 82%
GET/payments/{id}Paymentsagent-readytyped12 callersA · 92%
showing 8 of 214 · sorted by score, weakest firstlabels applied automatically, editable
03Consumption
Know who calls what before you change it
Elva traces each endpoint to the frontend pages, services, and MCP clients that call it, and flags the ones nobody calls at all. Deprecation stops being a guessing game.
Who’s consuming
Frontend pages14
Internal services23
MCP clients14
Unused endpoints31
GET /payments/{id} · callers
web/checkout/receipt.tsxfrontend page · 3 call siteshigh traffic
svc-reconciliationinternal service · nightly batchowner: platform
Claude DesktopMCP client · get_payment_status412 calls todayGET /v1/payments/{id}deprecated twin · still 40 calls/day from a partner
Change this endpoint and Elva knows exactly whose build breaks, which is what makes a contract enforceable.04Scoring
A grade per endpoint, and the fix to raise it
Design, developer experience, AI readiness, security, and performance, scored per endpoint. Weak specs float to the top of the catalog with a concrete fix attached, so the work is obvious.
Your API results by categoryScores per 12 API collections
100%75%50%25%0
Design92%
Developer experience84%
AI readiness71%
Security64%
Performance59%
Weakest endpoints, with the fix✦ Fix all with AI
GET/billing/legacy/invoicesD · 54%
No description, 6 untyped response fields, auth undocumentedFix: write description, type fields from code, document bearer authPOST/internal/debug/replayF · 22%
No auth defined, reachable in production, no consumers foundFix: mark internal, require scope, or retire itGET/ordersC · 68%
Unpaginated list, 4,100 tokens per agent callFix: add cursor pagination and a default limitcatalog averageC · 73%A · 91%
Always current
A catalog nobody has to maintain by hand
The reason API docs rot is that updating them is a second job. Elva keeps the catalog in sync with the only thing that is always true: the code.
Rescan on every commitNew endpoint merged at 4pm, in the catalog by 4:01 with a score and a suggested collection.
Auto changelogEvery added, changed, and removed endpoint is recorded with the commit behind it, breaking changes flagged.
Export anywhereOpenAPI 3.1, Postman collections, SDKs, docs sites, or an MCP server. The catalog is the source, not a dead end.
FAQ
How does Elva discover APIs without a spec?
It reads the repo in three passes: fingerprinting the frameworks in play, walking every route registration it can prove reachable, and recovering schemas from validators and serializers. The result is an OpenAPI 3.1 document generated from the code itself.
Which frameworks does Elva support?
Express, NestJS, FastAPI, Flask, Spring, Go routers (net/http, chi, gin), Rails, and more. Monorepos activate multiple extractors at once; the average repo activates 2.3.
How does the catalog stay current?
By rescanning the repo: manually on Free, weekly on Startup, and on every commit on Business and Enterprise. The catalog cannot drift from the code because it is derived from the code.
See your whole API surface in 42 seconds
Connect one repo. No spec file, no config, no credit card.