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?
Top comments (0)