Skip to content

Prototype · sample data, not real results

API Release Safety

Ship API changes. Customers get tested fixes.

Opted-in customers get a fix tested on both versions. You see counts, not code.

Register your API
Example from our demo repositories: Contacts API 2.0.0 renames display_name to full_name, so one integration gets a tested fix and one can't be proven. The fix shown is the known compatible repair from our demo fixtures.

You rename one field. A customer's code still reads the old one.

The Contacts API renames display_name to full_name in 2.0.0. The customer's app still works on 1.0.0, but on 2.0.0 the line return payload["display_name"] in src/client.py fails with missing_response_field.

Example from our demo repositories.

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.

You change your API. Your customers get a tested fix.

Every result keeps its evidence: pinned revisions, commands and exit codes.

  1. Catch the change

    You open a pull request that changes your API.

  2. Find the calls

    We find the customers who opted in and use what changed.

  3. Prove it breaks, then fix it

    We show their code breaks on the new version, then make a small fix.

  4. Pass both, or no pull request

    If the fix works on both versions, they get a pull request.

    Example

Examples from our demo repositories.

Know who your change breaks, without seeing their code.

Your contract's pull request gets a check that shows how many opted-in integrations are affected, how many have a tested fix and how many can't be proven. Never their code, repository names, files or logs.

Your pull request changes getContact: Contacts API 1.0.0 to 2.0.0 renames a response field. Its check says Needs attention: 2 opted-in integrations, 1 with a tested fix ready, 1 that can't be proven. Integration 1 gets a tested fix; Integration 2 can't be proven; an integration that has not opted in is not checked.

Example from our demo: one change, two opted-in integrations.

What you see

  • How many integrations are affected
  • How many have a tested fix
  • Sanitized reasons for the rest

What you never see

  • Their code or file paths
  • Repository names
  • Patches, logs or pull request links

Your customers get a tested fix before your API changes.

They choose the repositories and the APIs those call. When your contract proposes a breaking change, each opted-in repository gets a small fix that works with both versions, as a normal pull request they merge on their schedule.

One repository runs in a sandbox: the original passes on 1.0.0 and fails on 2.0.0, the fix passes on both, and a pull request is ready for review. Another repository's tests never call getContact, so it gets no pull request.

Examples from our demo repositories.

  • They choose what we watch

    Installing the GitHub App enrolls nothing.

  • Evidence, not a promise

    A fix counts only if their code passes against both versions.

  • A pull request like any other

    A small patch, the reason and the evidence. It never merges for them.

  • When it can't prove it, it says so

    No guessing, and no pull request.

Built to say no.

A fix has to earn its pull request. These rules are enforced in code and covered by tests.

Both versions must pass

A fix is offered only if it passes the customer's tests and a protected check of the changed call, on the current and the proposed API. Failed or inconclusive never becomes a pull request, and nothing is merged for anyone.

Opt in, per API

A customer repository is analyzed only after its admin enrolls it for a specific API. Installs that grant every repository are refused.

You see counts, not code

No repository names, file paths, patches, logs or pull request links.

A fresh sandbox every run

No credentials inside, no network while tests run, time and output limits, removed afterwards.

The fix sees only what it must change

The affected source files and your contract change. It can't edit tests, CI, dependencies or config: at most 5 files, 200 lines and 2 attempts.

Organization roles and resource ownership are checked on every request.

Questions API teams ask first.

  • 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. You never see any of it. 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. In a customer's repository it pushes its own branch and opens a pull request for a person to review. It never merges. Your repository only gets the check.

  • What if a customer's tests don't cover the changed call?

    Then that integration is inconclusive: no pull request for them, and your check counts it as can't be proven, never as safe.

  • Do I need to change how I ship?

    No. Keep opening pull requests against your OpenAPI contract. The check appears on them like any other, and you decide what to do with it.

  • Which stacks work today?

    REST APIs described with OpenAPI 3.0, and clients in Python or TypeScript/Node using common HTTP patterns. Verification currently covers GET operations with a path id and JSON responses. Behavior outside the declared contract is out of scope.

  • Do my customers have to do anything?

    Yes. You register your API; each customer opts in the repositories that call it. We cover only integrations that opted in, 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
    Open the live product

    Free hosting: the first visit can take about a minute to wake up.

  • Can I use it in production today?

    Not yet. It's a hackathon build on a development sign-in and a free hosting plan.

Start with one API.

Create a workspace, connect GitHub and register the repository that holds your OpenAPI contract. Nothing is analyzed until a customer opts in.

Register your API