Both versions must pass
A fix is kept only if it passes on the current and the proposed API. Anything less opens no pull request.
Change your API, and your customers get a tested fix.
You rename one field, and a customer's code still reads the old one.
The Contacts API renames display_name to full_name in 2.0.0. Most of its callers are unknown to the API team, and some of them still read display_name and fail with KeyError.
Before you release
You can't see whose code calls the operation you're changing, so you deprecate, email and wait.
After you release
Customers find out from a changelog or an error, then hunt for the call and patch it under pressure. Some never do, and the old version stays.
We move the fix to before your release.
Here is what happens when you open a pull request.
We find the opted-in customers who call what your pull request changes.
The change check on pull request 17 of the Contacts API: 1 of 2 opted-in integrations verified, 1 inconclusive. Needs attention.
We prove their code breaks on the new version, then test a small fix on both.
The evidence for contacts-client: the original code passes on the current API and fails on the candidate API, as expected. The fix passes on both.
They get a pull request only if the fix passes on both versions.
Example
The migrations for the change: contacts-client is verified and ready for review. health-only-client is inconclusive, so it gets no pull request.
Your customers stay in charge of their own code.
They choose what we watch
A Contacts API list: contacts-client and health-only-client are monitored, billing-client is opted out.
A fix counts only if it passes both versions
contacts-client's original code passes on 1.0.0 and fails on 2.0.0; with the fix it passes on both, so it is verified.
They decide whether to merge the fix
Example: The pull request in contacts-client is ready for review: it reads full_name instead of display_name, and merging it is the customer's call.
If we can't prove a fix, they get no pull request
health-only-client's tests never call getContact, so the run stops at Reproduce: inconclusive, and no pull request.
A fix has to earn its pull request.
Customers opt in per API
A repository is analyzed only after its admin enrolls it for your API.
You see counts, not code
No repository names, file paths, patches or logs reach you.
Every run gets a fresh sandbox
No credentials and no network while tests run, and it is removed afterwards.
The fix sees only what it must change
The affected source files and your contract change: at most 5 files and 200 lines.
Do you send my customers' code to an AI model?
Only the affected source files and your contract change go to the AI model that writes the fix, from our backend, never their tests or secrets. Their code runs in a fresh, isolated sandbox and the results stay in our own database, where you never see them. We haven't set a retention policy yet.
What does the GitHub App do in my repository?
On your repository it reads metadata and the contract, and posts a check on your pull request. On an opted-in customer repository it pushes its own branch and opens a pull request. The App asks for the same permissions everywhere: read metadata, write contents, pull requests and checks, only on repositories each side selects.
Will it push to main or merge?
No, it only pushes its own branch to a customer's repository and opens a pull request for a person to review, it never merges, and your repository only gets the check.
What if a customer's tests don't cover the changed call?
Then that integration is inconclusive, so they get no pull request and your check counts it as can't be proven, never as safe.
Do I need to change how I ship?
No, you keep opening pull requests against your OpenAPI contract, and the check appears on them like any other.
Which stacks work today?
It works with REST APIs described with OpenAPI 3.0 and clients in Python or TypeScript/Node that use common HTTP patterns. Verification currently covers GET operations with a path id and JSON responses, and behavior outside the declared contract is out of scope.
Do my customers have to do anything?
Yes, each customer opts in the repositories that call your API, and we cover only those integrations, within what their tests exercise.
What works today, and what's next?
Everything under "Working today" has run on our demo repositories and test fixtures, in our development setup. A check there says the migration was prepared, not that a customer's deployment works.
Working today
- Sign-in with organizations and roles
- Connect GitHub, selected repositories only
- Receive your pull request, pin the contract change and post a queued check
- Compare OpenAPI 3.0 contracts and find calls in Python and TypeScript
- Reproduce and verify in isolated sandboxes, against both versions
- Small fixes, at most 2 attempts
- Run every step automatically from your pull request
- Open the pull request in the customer's repository
- Report pass or fail on your pull request's check
Next
- A data retention policy
- OpenAPI 3.1 and more languages
Explore the clickable prototype (sample data)The first visit can take about a minute while the free host wakes up.
Can I use it in production today?
Not yet, because it's a hackathon build on a development sign-in and a free hosting plan.