What's Actually Inside a 4,000-Provider API Schema Corpus — and Why It's a Moat

By Aaron Gammon · Founder, Inferrex · June 2026

This is the spoke that grounds the lingua-franca piece in something concrete. That essay argues Inferrex is a shared language for business data; this one looks at the vocabulary of that language — the API schema corpus it's built from — and asks the questions a sceptic should ask about any big-number claim.

I keep live figures off the page deliberately: every count here resolves live and dated at inferrex.com/claims, because a corpus that grows every week shouldn't have its size frozen into an essay. Where I describe how the corpus is built, I keep to what it contains and produces, not the proprietary method behind it.

Every AI product now claims a big corpus, and "we've indexed thousands of APIs" has become background noise — partly because it's trivial to inflate. You can "cover" an API by noting it exists and grabbing its name and endpoint list. You can scrape a directory and announce a five-figure provider count by tea time. None of that tells you anything about whether the system actually understands any of those APIs, and the gap between "aware of" and "comprehends" is the entire difference between a marketing number and a real asset.

So the corpus count, by itself, is the wrong thing to look at — it's the connector-catalogue trap wearing different clothes, a tally of breadth that says nothing about depth. The questions that actually matter are three: how deep does each entry go, whether the schemas are normalised into something a system can reason across, and whether the corpus compounds or just accumulates. Let me take them honestly.

The first and most important distinction: there's a chasm between discovering that an API exists and reading its full specification.

Discovery is shallow — the provider's name, that it has an API, roughly what it's for. It's cheap, and on its own it's nearly worthless for comprehension, because you can't reason about a structure you haven't read. Reading the full specification is the deep version: ingesting the actual schema, every entity, every field, every relationship, every type — the complete machine-readable structure of how that provider models its corner of the world. That's the difference between knowing a book exists and having read it cover to cover.

The Inferrex corpus is built on the deep version. The figure that matters isn't how many providers have been noticed; it's how many have a full specification actually ingested and classified — entities, fields, and the integration pairs they make possible, all read and modelled, not merely listed. That funnel — from the broad universe of vendors that exist, down to those with a full machine-read spec, down to the curated library that's passed the quality bar — is exactly how I report it on the claims page, as a narrowing of depth rather than a flat boast of breadth, because the deep number is the honest one and the shallow one is the inflatable one.

A pile of schemas in two dozen different formats isn't a corpus you can reason across. It's a pile. The second thing that makes it an asset is that every one of those formats is normalised into a single canonical representation.

APIs describe themselves in a sprawl of formats — REST specs, GraphQL, gRPC and Protobuf, JSON Schema, the enterprise web-service formats, healthcare's own dialects like FHIR and HL7, the financial-messaging standards like SWIFT and FIX, the infrastructure-as-code formats, and many more. Each is a different way of writing down structure. A corpus that left them in their native formats would force every comparison to be a special case — you couldn't ask "which of these providers has a concept like this one's customer record" across formats, because they don't share a vocabulary.

Normalisation collapses all of that into one canonical model: every schema, whatever format it arrived in, parsed and re-expressed in the same internal language of entities, fields, and meanings. That is what turns a pile into a corpus — and it's the literal embodiment of the lingua-franca idea. The canonical model is the shared grammar; each provider's native format is a local dialect translated into it. Once everything speaks the one internal language, you can reason across all of it at once, which is the whole point. I make the conceptual case for this in the lingua-franca piece; the corpus is where that idea is made literal.

Let me give one concrete illustration of what "depth" means in practice, because it makes the abstract point tangible.

Apple's API surface isn't published as a tidy machine-readable specification the way many web services are. To actually comprehend it — to get the entities, the endpoints, and the thousands of individual properties into the canonical model — the structure has to be read and reconstructed into a full spec, not just linked to. Doing that yields a deep, classified representation of a major platform's data model that, as far as I'm aware, doesn't exist in machine-readable form anywhere else, because nobody else went and built it.

That's the difference between breadth and depth in a single example. A shallow corpus "covers" Apple by listing it. A deep corpus contains thousands of Apple's properties, classified by meaning, reasoned over alongside every other provider — because someone did the hard work of turning an un-specced surface into a fully-read one. Multiply that effort across the corpus and you start to see why the number that matters is depth-times-breadth, not breadth alone.

Here's the part that makes this commercially interesting rather than just technically satisfying: a deep, normalised, classified corpus is genuinely hard to copy, in a way a connector catalogue isn't.

A connector catalogue is just a list of integrations someone built; a competitor with enough engineers can build the same list. But a corpus of fully-read, normalised, classified schemas represents an enormous amount of accumulated comprehension — every spec ingested, every format normalised, every field classified by meaning, including the hard cases like un-specced surfaces that had to be reconstructed from scratch. You can't shortcut that by scraping a directory, because scraping gives you breadth without depth, and depth is the expensive, valuable part. And it compounds: every new provider added to the corpus doesn't just sit there as one more entry — it forms an integration pair with every provider already in it, so the useful surface grows quadratically while the corpus grows linearly. The asset gets more valuable per entry the larger it gets, which is the signature of a real moat rather than a feature.

There's a second-order effect too. Because the corpus is normalised into one model, each new provider often finds its concepts already partly understood — a previous provider contributed a structurally similar idea, and the new one slots into vocabulary that already exists. The corpus doesn't just accumulate; it gets more fluent, the way a living language gets richer with every dialect it absorbs. A competitor starting today isn't behind by the size of the corpus. They're behind by the size of the corpus plus all the compounding that's already happened inside it.

I'm wary of corpus-size bragging, which is exactly why I wanted to write the honest version. The number on its own is the shallow, inflatable metric — the connector-catalogue trap in new clothes. The real asset is everything the number doesn't capture: how deep each entry goes, that they all speak one canonical language, and that the whole thing compounds with every addition.

That's what's actually inside the corpus — not a list of APIs we've heard of, but a deep, normalised, classified body of comprehension that gets more valuable and more fluent the bigger it grows. It's the vocabulary of the lingua franca, and it's the part a competitor can't simply copy, because the depth was the whole job.