Apidrifter says 9 of 13 public APIs break generated clients

A team writes an OpenAPI spec. A client is generated from that spec. The spec says a field is a string. The live API returns a number. The code built from the spec throws. The team looks at the spec and the code and both look fine. The problem is that the two have moved apart.

Apidrifter is a new open-source tool that measures this gap. It was first pushed to GitHub on 2 November 2026. It has 87 stars. The author ran the tool on 13 public APIs against their own OpenAPI documents. They say 9 of the 13 returned responses that a generated client would break on. The author reports 171 places in the schemas where the two did not match.

The number, as the author reports it

The 9-of-13 number is the author's own measurement from the tool's own output. The test was read-only: it sent requests the specs described and read the responses. The author says the full method and the data are published alongside the code.

Three kinds of drift are counted. A field in the spec that is missing from the server's response. A field the server returns that the spec does not list. A type the server returns that does not match the one the spec declares. The engine has 26 rules of this kind.

The author's post of the finding does not name the 13 APIs. The project is three days old. No independent test of this number exists yet.

What the tool checks

Apidrifter runs an OpenAPI document against a running service and prints the mismatches, with a suggested fix for each. The fix is for the spec when the server is right, and for the server when the spec is right. The team picks.

The tool also compares two OpenAPI documents to each other, through 357 rules the author calls "spec-change rules". These know when a change breaks a client and when it does not. A field moving from optional to required breaks a sender. A field moving from required to optional breaks a reader. The tool reports the direction, not just the shape.

A third mode watches an MCP server, the server AI agents call. It reports when the tools, the arguments or the descriptions change between runs. An agent built last week against one set of tools will not notice when the server renames one. Apidrifter will.

How a team uses it

The command npx apidrifter run openapi.yaml runs the check from the terminal. The command apidrifter serve opens an MCP server that a coding agent in Claude Code or Cursor can call. A GitHub Action wrapper is also in the repository. The project is under Apache 2.0.

Two kinds of team will care. The first team sells an API to other developers. They can run the tool in CI and block a release that breaks a client. The second team depends on somebody else's API. They can run it on a scheduled job. They then find out when a vendor drifted, before the vendor's own release notes say so.

The tool is three days old. Its star count is modest. The 9-of-13 number is the author's own. The claim is simple. A working API with a 200 response can still break the people who use its spec. A short test will tell you. A team can run this test on their own services in an afternoon. That is true whether they sell the API or depend on one.

Source

apidrifter on GitHub, by apidrifter.