API Autopsy

From API changes to code-level answers.

Comment

Inspiration

Third-party APIs can change their response structures without going offline. An endpoint may still return a successful response while the application using it starts failing because an expected field has moved or disappeared.

Traditional uptime monitoring can tell developers when an API is unavailable, but it often doesn't explain what changed in the response, which parts of the application could be affected, or what code needs attention.

I wanted to explore a better approach: helping developers move from simply detecting an API change to understanding its potential impact on their code. That idea became API Autopsy.

What it does

API Autopsy is an AI-powered API contract monitoring and incident investigation tool for developers who rely on third-party APIs.

  • Detect: Establish a known-good response baseline and identify structural changes using a deterministic schema-diff engine.
  • Investigate: Search repository files for relevant code references using pattern-based matching.
  • Explain: Use Google's Gemini API to help explain potential application impact, likely failure paths, and root causes.
  • Propose a fix: Generate a suggested code patch that developers can review without automatically modifying their files.

The demonstration includes a controlled breaking-change simulation in which a top-level customer_id field is replaced by a nested customer.id field. API Autopsy detects the structural change and generates an investigation report with relevant demo-code evidence and a proposed update.

How we built it

I used the Devpost Learn AI Basics Skill Pack to guide the project through structured planning, implementation, testing, and shipping preparation.

Before coding, I developed planning documents including devpost/scope.md, devpost/prd.md, and devpost/spec.md. Using flipped interaction with an AI coding agent, I refined the requirements, reviewed technical decisions, and divided implementation into manageable stages.

The application uses Next.js and TypeScript for the web experience, PostgreSQL and Drizzle ORM for persistence, GitHub integration for repository access, and Google's Gemini API for AI-assisted investigation. A deterministic diff engine identifies structural changes before the AI analyzes their potential consequences.

I also added safeguards to distinguish canonical demo-fixture evidence from references obtained through an actual repository scan. Proposed patches remain reviewable suggestions rather than automatic code modifications.

Challenges we ran into

One major challenge was connecting an API contract change to potentially affected application code without presenting unsupported assumptions as facts.

A missing repository scan should not result in fabricated code references or an invented patch. Similarly, if Gemini fails, the deterministic change detection and incident information should remain available.

I addressed these challenges by separating deterministic detection from AI-assisted investigation, preserving evidence provenance, and handling incomplete analysis explicitly.

Another challenge was building a reliable end-to-end workflow—from baseline configuration and change detection to pipeline progress and the final investigation report—while keeping the project focused on a realistic proof of concept.

Accomplishments that we're proud of

I'm proud that API Autopsy goes beyond reporting that an API response changed. It brings structural detection, relevant code references, AI-assisted explanation, and proposed remediation together in one workflow.

I implemented a complete demonstration path that establishes a baseline, simulates a breaking change, records an incident, and produces an Autopsy Report.

I'm also proud of the safeguards around AI-generated results: structural detection is deterministic, evidence provenance is explicit, and suggested patches are not automatically applied to application code.

Most importantly, I turned an initial idea into a working full-stack proof of concept with a public source-code repository and documented engineering decisions.

What we learned

This project taught me to approach software development as a complete engineering process rather than just writing features.

I learned the value of defining scope before coding, documenting architecture decisions, testing failure scenarios, and separating deterministic system behavior from AI-generated reasoning.

I also learned that AI-powered developer tools need more than a capable language model. They need reliable surrounding systems, relevant evidence, clear uncertainty handling, and safeguards that keep developers in control.

Using the Learn AI Basics Skill Pack helped me connect planning, implementation, testing, and shipping into a more structured workflow.

What's next for API Autopsy

API Autopsy is currently a proof of concept, and there are several opportunities to expand it.

Next, I'd like to improve first-time onboarding with a guided setup that helps developers connect a repository, configure an API endpoint, establish a baseline, and run their first breaking-change simulation with fewer setup errors.

Future work could include deeper code analysis, broader API contract support, stronger automated monitoring infrastructure, and improved validation of proposed patches.

The long-term goal is to help developers spend less time investigating unexplained API failures and more time building reliable software.

Built With

Share this project:

Updates

Submission history