The collection overview

Open any collection and you land on a command center, not a file listing: who consumes this API, how it is secured, what changed recently, who owns the code, and how close it is to agent-ready. Every panel is computed from your source and your git history — none of it is hand-maintained, and all of it refreshes on the next scan.

A header that already knows your API

Before you scroll, the top of the page has introduced the collection better than most READMEs:

• The name and an auto-written summary of what the endpoints actually do (for a Billing collection: “reads, deletes, creates external-customer, checkout-session, check-subscription, auth”).
• The owner — the engineer with the most commits to this collection’s source files, not whoever created the page.
• Two badges pinning exactly what you are looking at: the commit the collection was built from and the OpenAPI version of its spec.

Three signals, front and center

Three cards sit above the fold because they answer the three questions every API owner gets asked.

Who’s consuming comes from Elva’s cross-reference pass over your own source: it counts the frontend pages and components that reach this API through its request wrappers, and flags unused endpoints that nothing references. This is consumption data most teams simply do not have — and it is the difference between “can I change this?” being a guess or a lookup.

Security Posture reads the contract the way an attacker would: what share of endpoints declare auth (auth coverage), how many define no auth at all, and whether HTTPS is enforced. A collection showing 0% auth coverage across 16 endpoints is not a style issue — it is a finding, surfaced before any agent or attacker finds it for you.

MCP Server closes the loop: the same collection you are auditing becomes a hosted MCP server without leaving the page, so “agent-ready” is a button, not a project.

Recent changes, mapped to endpoints

The overview’s change feed is not a wall of commit messages. Elva reconstructs it from git history and maps each commit to the exact endpoints it touched, so an entry reads like an API changelog: the commit message, a method-and-path badge such as

POST /stripe-webhook

, and when it happened. Release commits, version bumps, and bot noise are filtered out before anything reaches the feed.

That means “what changed in Billing last month?” is answered by scrolling, not by git log archaeology across a monorepo.

The details rail

Down the side, the rail compresses the collection’s health into numbers you can act on:

Ownership you can act on

The bottom of the rail answers the 2 a.m. question — who do I ping?

• Last commit: author, avatar, message, and a link straight to the commit on GitHub.
• Recent contributors: everyone who has touched this collection’s source files recently, identity-matched across git logins, names, and emails so one person does not appear three times.
• The owner at the top is computed the same way — most commits to the collection’s files, with release and bot commits excluded — so credit lands on the engineer who wrote the code, not the one who cut the release.

Where to go next

Endpoint intelligence

Drill from the overview into any endpoint: source file, request wrapper, and every component that uses it.

API testing

Fire a real request at any endpoint on this page without leaving the browser.