Why I Started Treating API Requests Like Code

AnkitSemwal007 — Tue, 11 Aug 2026 11:04:21 +0000

When working on an application, most important development artifacts live in the project repository.

Source code is in Git. Configuration is in Git. Database migrations are in Git.

But API requests often live somewhere else.

You create requests in an API client, organize them into collections, configure environments, add tests, and then that workflow stays inside a separate application.

I started wondering:

Why can't API requests simply be part of the project?

That question led me to build API Hero, a Git-first REST/HTTP API client for VS Code.

The basic idea

Instead of keeping an API request only inside a separate tool, API Hero stores requests as .api files.

For example:

my-project/
├── src/
└── api/
├── users.api
├── products.api
└── orders.api

Now the API request is a normal project file.

That means it can be:

committed to Git
reviewed in pull requests
compared with previous versions
shared with the team
branched and merged
kept alongside the code that uses the API

The goal isn't just to use a different API client. It's to make API requests first-class development artifacts.

More than just request files

Once requests are project files, the rest of the API workflow can be built around them.

API Hero supports:

Request editor
Collections and folders
Variables and environments
Authentication
Assertions
Collection Runner
Run reports
Request history
Scenarios
OpenAPI workflows

Assertions are particularly useful because the same requests can be used for development and testing.

For example, an API might return:

HTTP 201

while the test expects:

HTTP 200

The request itself succeeded. The assertion failed.

API Hero exposes the expected and actual values so the difference is clear.

Why VS Code?

I wanted API work to stay close to the development workflow.

If I'm working on an application and need to test an endpoint, I shouldn't necessarily have to leave my editor, open another application, find the right collection, configure the environment and run the request.

With API Hero, the request is already in the workspace.

The same files can be used by developers, collections and automated workflows.

Then AI agents changed the idea

The .api approach became even more interesting with AI coding agents.

An AI agent can already read files in a repository.

But reading an API request is different from actually executing it.

So API Hero now includes a standalone MCP server that allows compatible AI agents to interact with the API workflow.

An agent can:

Discover collections
Inspect requests
Run requests
Run collections
Retrieve responses
Inspect execution results
Diagnose assertion failures

The important part is that MCP doesn't implement another HTTP client.

It uses the same API Hero execution pipeline:

AI Agent
↓
API Hero MCP
↓
Collection Runner
↓
Execution Engine
↓
API
↓
Response
↓
Structured result

This means the API execution logic doesn't have to be duplicated for AI agents.

A simple example

Suppose an AI agent runs a request and receives:

HTTP 201

But the test expects:

HTTP 200

Instead of simply reporting that the API request failed, API Hero can provide:

HTTP request: successful
HTTP status: 201

Failure category: assertion
Expected: 200
Actual: 201

The agent can then understand that the API responded successfully and that the test expectation is what needs attention.

That's the part of the project I'm particularly interested in exploring.

The bigger idea

The direction I'm experimenting with is:

API request
↓
Project file
↓
Git
↓
Developer / Tests / AI Agent
↓
Same API execution engine

The request becomes a shared artifact.

A developer can edit it.

Git can track it.

A collection can execute it.

Tests can validate it.

An AI agent can use it.

What API Hero is today

The current release, 2.8.2, includes:

Git-first .api request files
Request editor
Collections
Variables and environments
Authentication
Assertions
Collection Runner
Run reports
Request history
Scenarios
OpenAPI
Standalone MCP server
AI-agent API execution
Failure diagnostics
Secret redaction

API Hero is available as a VS Code extension.

GitHub:
https://github.com/ankitsemwal007/api-hero

VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=AnkitSemwal.api-hero

I'm interested in the underlying idea more than the product itself:

Would you find it useful if API requests were first-class files in your Git repository, alongside the application code?

Or do you think API requests are better kept inside a dedicated API client?

DEV Community: AnkitSemwal007

Why I Started Treating API Requests Like Code