Redocly builds the spec from traffic, and says exactly where the AI is allowed

Redocly builds the spec from traffic, and says exactly where the AI is allowed

Redocly has shipped a second command for getting an API surface written down, and this one starts from the only source that cannot be wrong about behavior. In Generate OpenAPI from real traffic (with AI), Adam Sobaniec states the problem in terms this series cares about: “an OpenAPI description is the contract AI agents read to learn how to call an API,” and plenty of production APIs have none. Asking a model to derive one from source “fails on large codebases: the model loses context, hallucinates API behavior, and generates convincing but subtly inaccurate descriptions that are impossible to verify.” The new generate-spec command reads recorded traffic instead, HAR files, Kong logs, Nginx and Apache JSON logs, or NDJSON, and builds a baseline deterministically before a model touches anything.

There are no vendor figures to weigh, and the design choices are what make the post worth reporting. The inference is conservative on purpose. Identifier-like path segments become named parameters “so a hundred URLs become one templated path.” A property “becomes optional as soon as one sample omits it.” A string becomes an enum only when it repeats in every observation, and a query parameter seen twice stays a plain string because “two observations are not enough evidence.” The AI is used “selectively - processing one endpoint at a time, grounding every change in real data, and verifying all output.” And there is a warning most tools would bury: a capture “contains whatever that traffic contained, including credentials and personal data,” and “observed values end up in the generated description as enums and examples, so a description inferred from real user data is not safe to share either.” The worked example outputs a valid OpenAPI 3.2 document.

The catalog has a stake in this one, because apis.io does a version of the same thing. When a provider publishes no contract, the catalog generates one from its documentation, marks it as generated, and keeps it out of the provider’s credit. A contract inferred from traffic needs the same label, and the post’s care about evidence is the right instinct. The Redocly provider page lists 16 API pages, and the command lives in the Redocly CLI, next to the introspect-mcp command this series covered ten days ago. The agentic access profile maps 15 operations, 8 of them acting, and it is new: that dimension was unlit when the last post was written.

The Kin Score is 82.6, exemplar band, up from 75.5 in that earlier post, with access clarity and operational transparency both at 100.0, developer ergonomics at 78.6, and contract governance at 45.5. The Agent Readiness score is 32.7, agent-ready, with the MCP server, agent skills, and the well-known catalog lit. The identity layer is still dark: delegated identity, protected resource metadata, and dynamic client registration are unlit, along with idempotency. Redocly has now shipped two commands that turn an undocumented surface into a contract, one from an MCP server and one from the wire. Both produce a description of what was observed. The question the post half asks is the one that matters for anyone publishing the result: a contract inferred from traffic should say so, in the document, so the next reader knows it was watched rather than written.

← LogicMonitor says monitor the agent journey like an API, and its own record mostly holds up
Routebase asks which copy of the spec is current, and its own governance scores 4.5 →