Skip to content
Constova

A GitHub App for API teams

Change your API without breaking your customers.

A GitHub App that finds the customer code your change breaks, tests a fix on both versions, and sends it as a pull request.

Register your API
Example: customer repositories whose code your change breaks pass through Constova. Each one gets a fix tested on the current and the new version of your API. A fix that passes both arrives as a pull request; a fix that can't be proven gets no pull request.

Works with

  • GitHub
  • OpenAPI
  • Python
  • TypeScript

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.

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.

Here is what happens when you open a pull request that changes your API.

  1. Your pull request gets a check that shows how many opted-in customers your change affects.

    The change check on pull request 17 of the Contacts API: 1 of 2 opted-in integrations verified, 1 inconclusive. Needs attention.

  2. An AI agent writes a small fix, and we test it on the current and the new version.

    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.

  3. They get the fix as a pull request, but only if it 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.

Examples from our demo repositories.

Your customers stay in charge of their own code.

  • You invite them, and they choose which repositories we watch.

    The customer's Monitored APIs list for Contacts API: contacts-client and health-only-client are watched, and billing-client is opted out.

  • 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.

Examples from our demo repositories.

A fix has to earn its pull request.

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.

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.

API teams ask these questions 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, 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, you invite them by email, and each customer opts in the repositories that call your API. 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.

Start with one API.

Register your API