Inferring API Structure: How a System Reads an API It Has Never Seen Before

By Aaron Gammon · Founder, Inferrex · June 2026

This is a technical-credibility piece, and it carries my strict standing rule: I'll describe what the system does and what it produces, never how it's trained or structured. The inference machinery is the proprietary core — I sell what the factory makes, not the schematics — so you'll find capabilities and outputs here and deliberately no blueprint.

It's the spoke under my self-healing pillar: self-healing is impossible without the ability to re-read a changed API, and that ability is the same one that lets the system read an unfamiliar API in the first place. Live figures, including corpus and model status, at inferrex.com/claims.

Every connector-catalogue platform has the same shape of gap, and it's defined by what's not in the catalogue. The model works like this: a human, at some point, studied a provider's API, decided what each field meant, and built a connector. From then on, the platform "supports" that API — meaning a person already did the understanding and froze it into a connector.

Which means the platform is helpless the moment it meets an API no human pre-studied. And those are everywhere: the internal service your own company built that has no public docs, the niche industry vendor too small for anyone to bother cataloguing, the partner's bespoke system, the legacy platform whose documentation was lost two reorgs ago, the brand-new API that launched last week. For all of these, the catalogue's answer is the same — build a custom connector, which means hire the human time to study it and freeze it, which is a project, a cost, and a wait.

The connector-shaped hole is the entire long tail of real-world integration. And the long tail is where most of the actual pain lives, precisely because it's the part the catalogue economics will never reach.

The alternative to a human pre-studying every API is a system that can read one itself.

That's the distinction. A connector is the system being told, in advance, what an API means. Inference is the system reading the API directly — from its specification where one exists, and from its live responses where one doesn't — and working out its structure on the spot. No human has to have seen this particular API before. The system encounters it, reads it, and understands it, the same way a fluent reader can pick up a document they've never seen and understand it without anyone having pre-summarised it for them.

This is why "an API it has never seen before" is the real test, and the one the catalogue model can't pass. Being told about a known API is the easy case — someone did the work already. Reading an unknown one, with no human in the loop and no pre-built connector, is the capability that actually matters, because it's the one that closes the connector-shaped hole instead of pricing it as a custom project.

I'll describe what the reading produces, because the outputs are the part worth understanding and the part I can share freely.

Pointed at an API, the system first establishes the raw structure — detecting how to talk to it and reading whatever schema it can, whether from a published specification in one of many formats or by probing the live responses of something undocumented. That gives it the shapes: the entities, the fields, the relationships, as raw structure.

Then comes the part that matters, which is moving from structure to meaning. A raw field name and type tells you almost nothing useful — cust_ref_2, string. The valuable output is the classification of that field by what it means in business terms: this is a customer identifier, that is a monetary amount, this other one is an email address — each with a confidence attached, so genuine ambiguity is flagged rather than guessed. From the classified fields, it infers how the entities relate, attaches plain-English meaning, and proposes how this newly-read system's fields correspond to others. The output isn't "here's the schema." It's "here's what this API means, in terms you and every other system can use" — raw structure turned into understood, classified, business-meaningful concepts.

It's worth dwelling on why this specific capability — reading the genuinely unfamiliar — is the one that separates comprehension from cataloguing.

Anyone can appear to handle the well-known APIs; you just pre-build connectors for the popular ones and you'll look capable in every demo, because demos use popular APIs. The catalogue model is optimised for exactly that impression. But the popular, stable, well-documented APIs are the easy part of any real integration estate. The hard part — the part that generates the backlog, the custom-connector projects, the "we don't support that yet" — is the long tail of the bespoke, the niche, the internal, and the undocumented. A system that can only handle what a human pre-taught it has, by definition, abandoned you exactly where you most need help.

Reading an unseen API is the capability that turns the long tail from a series of custom projects into just more for the system to comprehend. That's the test, and it's a test the catalogue model is structurally unable to pass, because its whole premise is that a human went first.

Concretely, being able to read an unknown API changes what's possible rather than just what's faster.

The undocumented internal service your company depends on becomes integrable without a documentation archaeology project. The niche vendor that no catalogue will ever cover becomes a first-class connection rather than a permanent exception. The one-off, the partner system, the acquired company's stack, the legacy platform — all the things that used to be "out of scope" or "custom project, next quarter" — become things the system simply reads and comprehends. The long tail stops being the place integration goes to die. And because the same reading capability is what lets the system re-read an API that has changed, it's also the foundation of self-healing: re-inference on a changed provider is just inference run again. The capability that opens the long tail is the same one that keeps everything repaired.

I keep the inference machinery itself proprietary, but I'm happy to be loud about what it does, because the capability is the thing that makes everything else possible. Self-healing needs it. Closing the long tail needs it. The whole comprehension-over-connection argument rests on it, because comprehension is the system reading and understanding for itself rather than being pre-told.

The connector catalogue was a way of pre-paying the understanding cost, one human study at a time, for the APIs deemed worth it. Inference pays that cost automatically, for any API, the moment it's encountered. That's not a faster catalogue. It's the end of needing one.