Try Constova: www.constova.dev
Inspiration
Our teammate Rishi works at Autodesk, and his experience helped shape Constova’s inspiration: the gap between an API provider announcing a change and a customer updating their integration.
Consider a construction project like Riverside Tower. Every morning, the site supervisor relies on an application connected to Autodesk to access the latest drawings. If that application still calls a retired authentication endpoint, the drawings stop refreshing, even while Autodesk’s services are operating normally.
The provider may have announced the retirement weeks earlier. The engineering team may have read the announcement and added the migration to its backlog. But competing priorities can leave the update unfinished until the application stops working.
That scenario captures the problem we wanted to solve. Announcing a breaking change does not ensure that the applications depending on it are ready.
Coding agents opened up a different possibility: API providers could deliver migration code directly to the repositories that need it. We built Constova to make that workflow possible.
What it does
Constova connects API providers to their customers’ codebases, turning breaking API changes into tested pull requests.
Providers register their APIs and connect GitHub. Customers explicitly enroll the repositories that depend on those APIs.
When a provider proposes a breaking change, Constova:
- Compares API contracts to identify what changed.
- Finds affected usages in enrolled customer repositories.
- Generates a focused compatibility repair.
- Tests the repair against the current and proposed API versions.
- Opens a customer pull request when verification succeeds.
Customers review and merge updates through their existing GitHub workflow. Providers see aggregate migration results, while customer source code, patches, and logs stay private.
Think of it as Dependabot for API integrations.
How we built it
We built Constova as a TypeScript monorepo with a Next.js frontend, a Fastify backend, and PostgreSQL through Drizzle. Clerk manages identity and workspaces, and a GitHub App handles repository connections, checks, and migration pull requests.
The analysis pipeline compares OpenAPI contracts and traces supported TypeScript and Python HTTP usages. Claude proposes bounded code repairs, E2B executes verification in isolated sandboxes, and Render Workflows coordinates background jobs.
Before publishing a repair, Constova requires four pieces of evidence:
- The original integration works against the current API.
- The original integration fails against the proposed API at the affected operation.
- The repaired integration still works against the current API.
- The repaired integration also works against the proposed API.
This makes verification part of the publication decision.
Tracks we're competing in
Best Use of Clerk: Clerk powers sign-in, organization workspaces, and membership verification. We combine Clerk identity with backend authorization to keep provider and customer resources separate and restrict sensitive actions to workspace administrators.
Best Use of SurrealDB Agent Memory: Constova stores source-linked lessons from verified repairs and failed approaches, then recalls relevant context for future migrations. Memory is scoped to each customer repository and enrollment, and every generated repair still requires fresh verification before becoming a pull request.
Challenges we ran into
Connecting contract changes to customer code. Detecting a changed endpoint or response field is only the beginning. We needed to locate the actual requests and field usages that depend on it.
Proving that a repair works. Passing tests can be misleading when they never exercise the affected operation. We built verification that requires evidence of the relevant behavior and returns “Needs review” when coverage is insufficient.
Handling migration timing. A customer may merge its repair before the provider releases the change. The update therefore needs to preserve compatibility with both API versions.
Coordinating work across organizations. Repository permissions, customer consent, background execution, and GitHub events have separate lifecycles. We had to preserve revision identity, recheck authorization, and handle retries without publishing duplicate pull requests.
Accomplishments that we're proud of
We completed the workflow from a proposed API change to an actual, verified customer pull request.
In our Autodesk-inspired hosted demo, Constova identified a retired authentication endpoint in a Python drawing-sync integration. It reproduced the failure, generated a compatible repair, verified it against both API versions, and opened a GitHub pull request.
A second integration lacked sufficient coverage of the affected operation. Constova correctly flagged it for review and withheld a pull request.
We’re proud of both outcomes: delivering a useful repair and recognizing when the available evidence was insufficient.
What we learned
Generating a plausible patch is only one part of maintaining an integration. Proving that it fixes the intended failure, preserves compatibility, and is appropriate to publish requires much more work.
We also learned that API availability and integration compatibility are different things. A provider can be fully operational while a customer’s application remains broken.
Useful automation needs clear evidence and clear limits. Developers should be able to understand what changed, inspect the verification results, and retain control over the final merge.
What's next for Constova
Our current implementation focuses on breaking-change migrations for supported OpenAPI, TypeScript, and Python patterns.
Next, we want to broaden API and language coverage, support more complex authentication and integration patterns, and pilot Constova with API providers and their customers.
Beyond breaking changes, we want to help customers adopt useful new API capabilities. Our longer-term goal is to make maintaining API integrations a routine part of software delivery, with providers delivering tested code updates alongside their releases.
Built With
- claude
- clerk
- drizzle-orm
- e2b
- fastify
- github-api
- next.js
- node.js
- openapi
- postgresql
- python
- react
- render
- render-workflows
- typescript
Log in or sign up for Devpost to join the conversation.