API Contract Checker for Continuous Integration
Backend teams break their own clients constantly: a field is renamed, a response type changes, a required parameter appears, and nothing fails until something in production does. Build a tool that compares the API a branch produces against the API on the main branch, classifies every difference as safe or breaking, and fails the build when a breaking change arrives without a version bump. Unglamorous, genuinely useful, and small enough to finish properly.
Intermediate
A small team, or one strong student willing to learn something new.1 semester · 2 students
7 to ship
3 optional extrasSuggested stack
What you should ship
- A generator that produces an OpenAPI description from a running service, or reads a committed one
- A comparison engine that classifies each difference as additive, breaking or cosmetic, with the rules documented
- A GitHub Action that runs on every pull request and comments with the differences it found
- Configurable policy, so a team can decide which change classes fail the build
- Detection of undeclared breaking changes, meaning a breaking change with no matching version increment
- A dashboard showing how each endpoint's contract has changed over time
- An evaluation run against the history of at least three open source APIs, checking whether real breaking releases are caught
If you have time left
- Recording which fields real clients actually use, so unused field removals can be downgraded
- Support for GraphQL schema comparison alongside REST
- Suggested deprecation notices generated for each breaking change
The problem
API breakage is a communication failure with a technical shape. The backend team knows they renamed a field. The three teams consuming it find out when something stops working.
Versioning is supposed to prevent this, and it does not, because nothing checks that the version was actually bumped when it needed to be.
What makes this a real project
- Classification is the whole thing. Adding an optional field is safe. Adding a required parameter is not. Making a response field nullable breaks clients that assumed it was not. Getting this taxonomy right, and defending it, is the core of the work.
- False positives kill adoption. A checker that cries breaking change over a reordered enum will be switched off in a week. Being conservative in the right direction matters more than catching everything.
- It has to be fast. Anything that adds minutes to every pull request gets disabled. Budget yourself seconds.
- Real validation is available. Open source APIs have public version histories. Run your tool across them and check whether it flags the releases that were actually documented as breaking. That is a genuine evaluation, not a synthetic one.
Suggested approach
Start with a hand written comparison of two OpenAPI files and a small rule set. Grow the rules from real cases you find in the wild rather than from imagination.
Wire it into CI early, on your own project, and live with it. You will find the annoying false positives quickly.
How you will know it worked
Run it over a year of releases from a real API and compare what it flagged against the project's own changelog. Every breaking change they announced that you missed, and every one you invented, goes in the evaluation.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.
Follow along
New writing, resources and project ideas land here first.