Reverse engineer API: the schema is a clustering problem

Put a language model on the hardest step of API recovery and it can make things much worse. In the benchmark behind APISENSOR, a prompt-based log-template miner scored 92.86% on one application; the same tool's GPT-5 variant scored 28.57%. If you need to reverse engineer API structure from captured traffic before an ERP deadline, the method that wins is still denoising, clustering and human review.

That is a useful thing to know before you scope the work, because the tooling conversation in 2026 implies the opposite. This post covers what the best-measured method actually does, the one released tool that genuinely puts a model on the inference step, the five things traffic capture can never tell you, and the decision procedure to run before you capture a single packet.

What the 2026 benchmark actually measured

APISENSOR (arXiv:2603.23852, submitted 25 March 2026) is a black-box framework that reconstructs an application's API surface from runtime traffic logs without supervision. Across six open-source web applications — Train-Ticket, HumHub, Memos, Overleaf, Nextcloud and Dify — and over 10,000 runtime requests with simulated mixed-traffic noise, it reports an average Precision of Group Accuracy of 95.92% and an F1-score of Group Accuracy of 94.91%, against ten baselines.

The architecture is the interesting part. The paper describes "traffic denoising and normalization with a graph-based two-stage clustering process". Stage one strips static assets and non-API content types, normalises paths, then feeds path segments into a fixed-depth prefix tree using Drain3, so that /api/v1/items/123 and /api/v1/items/456 collapse into /api/v1/items/*. Stage two separates requests that share a path shape but behave differently, using a similarity graph built over hand-picked features: path depth, query parameter count, body size, field count, nesting depth. Where the graph is too sparse, it falls back to K-means.

There is no language model anywhere in that pipeline. Every component is a statistical or graph method over features an engineer chose. The paper is motivated by LLM agents needing reliable API knowledge, and that motivation is easy to misread as the method.

The baseline table is where the counter-intuitive result lives. LogPPT is a prompt-based template miner, and the authors ran both its RoBERTa-based and GPT-based variants. Comparing the GPT-5 variant against plain token n-gram statistics on the same six applications, the generative variant scored lower on five and tied on the sixth:

Application	LogNgram (F1 of group accuracy)	LogPPT, GPT-5 variant
Train-Ticket	92.86%	28.57%
HumHub	78.26%	78.26%
Memos	86.21%	28.07%
Overleaf	62.63%	40.48%
Nextcloud	88.37%	41.86%
Dify	79.82%	47.06%

The paper also characterises the tools most teams reach for first. Optic and Mitmproxy2Swagger, it says, "generate OpenAPI specifications from HTTP request–response traces or intercepted network traffic, but they mainly rely on heuristics and shallow structure inference". That characterisation is worth taking seriously for a second reason: as of October 2026 the Optic repository is archived, with its last push on 8 January 2026 and a README pointing at Optic Labs joining Atlassian. mitmproxy2swagger is still active, and its documented workflow is explicitly two-pass: it emits candidate path templates and you edit the file by hand to choose which ones become endpoints. The human review step is not a weakness in that design. It is the design.

One 2026 release does put a model on the inference step

The claim that no shipped tool uses a model for schema inference itself does not survive contact with the registry. Spectral (pip install spectral-mcp, version 0.11.0, published 27 March 2026) records traffic through mitmproxy and, in its own words, "uses an LLM to understand what each call does". It lists pydantic-ai-slim[anthropic,openai] as a hard dependency, not an optional extra.

This is not marketing gloss over a regex. The module that produces endpoint patterns opens with the docstring "Group URLs into endpoint patterns using LLM", and its prompt instructs the model directly: "Group these observed URLs into API endpoints. For each group, identify the path pattern with parameters… Even if you only see ONE value for a segment, if it looks like an ID (numeric, UUID, hash, base64-like), parameterize it." The model gets decoding tools for opaque segments and names parameters from the preceding resource — /projects/123 becomes /projects/{project_id}.

Two honest qualifications. First, the split: the model owns path templating and parameter naming, while request and response body shapes come from a module whose own docstring reads "Mechanical extraction of endpoint specs from grouped traces" — sample merging, then model-written descriptions on top. So even the model-native tool keeps deterministic extraction for the types. Second, scale: Spectral had 121 stars and no push since 31 March 2026 when we checked, and publishes no accuracy benchmark. It is a real counter-example to "nobody has tried this", not evidence that the approach measures better.

So the defensible version of the claim is narrower and more useful: putting a model on endpoint grouping is now a shipped idea, and the only method with published numbers against ten baselines still does not do it.

How to reverse engineer API traffic into a schema you can build on

The workflow that survives an audit has four steps, and the middle two are where the time goes.

1. Capture breadth, not volume. Drive every workflow you intend to integrate, including the failure paths — a rejected payment, an expired token, a validation error. Ten thousand requests through three screens tells you less than four hundred through thirty.
2. Cluster and normalise. Collapse identifier segments into templates, group by method plus normalised path, then merge body samples per group. This is mechanical and you should let a tool do it.
3. Review every endpoint with a human. Someone decides which candidate templates are real endpoints, which are noise, and which optional field is optional because it was genuinely absent versus because your capture never triggered it. Nothing in the 2026 tooling removes this step.
4. Freeze it as contract tests. The recovered spec is a hypothesis. Contract tests against the live vendor endpoint turn it into something that tells you, in CI, the morning the vendor changes it.

Step four is the one buyers cut first and regret. A recovered schema has no changelog and no deprecation notice behind it. Compare that to a vendor who does document and does version: HubSpot's own API deprecation schedule for v1 to v3 gave integrators dated warning. An undocumented endpoint gives you a 500 on a Tuesday.

What traffic capture cannot tell you

This is the part under-scoped in almost every integration estimate we see. Capture is a record of what happened once. It is not a specification, and the gap is not a matter of better clustering.

What you need to know	Does capture answer it?	Where the answer comes from
Endpoint paths and methods	Yes, with review	Clustering over captured requests
Field names and types you exercised	Mostly	Sample merging across requests
Fields absent from your sample	No	Vendor confirmation; a wider capture
Error semantics and retry-safe failures	No	Deliberate failure testing, in writing
Rate limits and quota windows	No	The contract, or the vendor
Idempotency guarantees	No	The vendor, explicitly
Future schema drift	No	Contract tests in CI

Idempotency is the expensive one. Nothing in a captured POST tells you whether retrying it after a timeout creates a second order. You cannot infer that property from traffic at any accuracy, because the evidence for it does not appear in the traffic. You get it by asking, and you get it in writing.

The absent-field problem is subtler and APISENSOR's own case study shows the inverse risk. Evaluating against Dify, the authors found endpoints that "repeatedly appeared in network traffic traces but were missing from the API Reference" — including /console/api/apps/{id}/api-keys. They reported it, and a core collaborator acknowledged the reference had fallen out of sync with the implementation. Capture and documentation each see things the other misses. Treat disagreement between them as a question for the vendor, not a bug in your capture.

Is it legal to reverse engineer an API? Read the contract first

Probing an API you are contractually barred from probing is a legal question before it is an engineering one, and the honest answer is a procedure rather than a holding. Terms of service and contract terms can bind you even where the technique itself is lawful, so "this is just HTTP" is not a defence to a clause you signed.

The ground is also moving. The US Copyright Office opened its tenth triennial DMCA section 1201 rulemaking on 9 June 2026, a notification of inquiry requesting petitions for new and renewed exemptions to the prohibition on circumventing access controls. Petitions closed 24 August 2026 and comments on renewal petitions closed 28 September 2026; as of October 2026 the proceeding has not concluded. Anyone telling you the 2026 position on circumvention exemptions is settled is describing a proceeding that is still open.

So the procedure, in order:

• Read the agreement you actually signed — the master services agreement and the API terms, not the marketing page. Look for clauses on reverse engineering, automated access, and permitted integration methods.
• Ask the vendor in writing. "We intend to integrate against endpoints X and Y; please confirm this is permitted and tell us the rate limits." A yes by email is worth more than a recovered schema, and the answer often arrives with documentation attached.
• Involve counsel before you capture, not after, if the agreement is ambiguous or the data is regulated.

Note the frame this whole post assumes: you are integrating with a system you are already authorised to call, as a licensed customer of it, capturing your own session traffic. That is a different activity from bypassing an access control or scraping a service whose terms forbid it. If your situation is the second one, the engineering is the least of your problems.

What this means for an ERP or CRM integration you are scoping

We build API development and integrations work into platforms that have to talk to systems we do not control, and the undocumented vendor endpoint is a standing feature of it rather than an exception. When we unified HR, CRM, inventory and finance for a large-scale industrial client's custom ERP, the integration surface — not the feature list — set the schedule.

Two practical consequences for your estimate. Scope the human review explicitly as its own line item, because it does not compress: a tool proposing four hundred candidate endpoints has handed you four hundred decisions. And treat contract tests as part of the integration, not as QA you can defer, because they are the only mechanism that will tell you about drift in a schema nobody publishes. That is the same reasoning as treating vendor lock-in as a reversibility problem: what matters is not the dependency, it is whether you find out when it moves.

The next decision is not which tool to buy. It is whether you can get the vendor to answer three questions in writing — rate limits, idempotency on retry, and notice before a breaking change. If they will, the schema recovery is a week of clustering and review. If they will not, you are building against a moving target, and the honest estimate includes the contract tests and the monitoring that implies. For integrations where a regulator is also watching the payload, such as e-invoicing ERP integration in the UAE, that answer in writing is not optional at all.