DEV Community: AnkitSemwal007

API Hero: Beyond API Requests — Building Executable API Workflows

AnkitSemwal007 — Mon, 14 Sep 2026 09:48:17 +0000

How API Hero connects API collections, dependencies, authentication, variables, testing, automation, and AI-assisted API workflows.

Most API clients start with a simple problem:

Send an HTTP request and show me the response.

That problem is largely solved.

The more interesting problem begins when you have dozens or hundreds of requests that depend on each other.

A real API workflow rarely looks like:

GET /products

It looks more like:

Login
↓
Get authentication token
↓
Get products
↓
Create product
↓
Extract product ID
↓
Update product
↓
Delete product
At that point, API testing is no longer just about sending requests.

It becomes a workflow problem.

That's the problem I'm exploring while building API Hero.

6
Why API Hero focuses on workflows

Individual API requests are easy to understand.

The relationships between requests are where things become complicated.

Consider:

POST /auth/login
GET /products
POST /products
GET /products/{id}
PUT /products/{id}
DELETE /products/{id}

These aren't necessarily six independent operations.

They might form a workflow:

POST /auth/login
│
└── accessToken
│
├── GET /products
│
└── POST /products
│
└── productId
│
├── GET /products/{id}
├── PUT /products/{id}
└── DELETE /products/{id}

The API itself already contains these relationships.

API Hero is being designed to understand and work with those relationships.

API Hero Collections are more than folders

The starting point is the collection.

For example:

FakeStoreAPI

├── Auth
│ └── Login User
│
├── Products
│ ├── Get All Products
│ ├── Get Product By Id
│ ├── Add Product
│ └── Update Product
│
├── Carts
│ ├── Get All Carts
│ ├── Get Cart By Id
│ ├── Add Cart
│ ├── Update Cart
│ └── Delete Cart
│
└── Users
├── Get All Users
├── Get User By Id
├── Add User
└── Update User

A collection provides context.

Once requests are grouped together, we can start asking:

Which requests require authentication?
Which requests produce variables?
Which requests consume those variables?
Which endpoints are related?
Which requests can run together?
Which requests should become a scenario?
Which tests should be generated?

That makes the collection a useful foundation for API understanding.

Variables create data flow

Consider a login response:
{ "token": "abc123..." }

Another request may use:

Authorization: Bearer {{token}}

There is now a dependency:

The same applies to resource IDs.

Create Product
↓
Response
↓
productId = 123
↓
Update Product
↓
Delete Product

Variables therefore aren't simply placeholders.

They can represent data moving through an API workflow.

API Hero uses this concept when building executable scenarios and preparing collections.

Authentication is part of the workflow

Authentication creates another layer of dependency.

An API collection might contain:

Public endpoints
+
Authentication endpoint
+
Protected endpoints

For example:

POST /auth/login
↓
token
↓
Authenticated context
↓
GET /products
POST /products
PUT /products/{id}
DELETE /products/{id}

The important question isn't only:

Does this endpoint require authentication?

It's also:

Where does the authentication come from, and how does it get into the request?

That's why API Hero treats authentication, variables, and dependencies as connected parts of the workflow.

API Hero Scenarios

Once dependencies are understood, we can create scenarios.

A scenario represents an executable workflow rather than simply a list of requests.

For example:

Product Lifecycle

Login
Extract authentication token
Get products
Create product
Extract product ID
Get product
Update product
Delete product

The important part is the relationship between the steps.

Step 5 needs information produced by step 4.

Step 7 needs the ID produced earlier.

The scenario therefore represents the actual execution flow of the API.

This is one of the areas where API Hero goes beyond treating API requests as isolated objects.

API Hero and API testing

Once requests are connected, testing becomes part of the same workflow.

A request can contain assertions such as:

Status = 200
Response time < threshold
Required property exists
Property has expected type
Response contains expected value

Negative testing can cover:

Invalid authentication
Missing required parameter
Invalid resource ID
Malformed request
Unauthorized operation

The execution flow becomes:

Request
↓
Execute
↓
Response
↓
Assertions
↓
Pass / Fail

For a scenario:

Request
↓
Extract data
↓
Pass data forward
↓
Next request
↓
Assertions
↓
Scenario result

This allows API testing to happen at both the request level and the workflow level.

Where AI fits into API Hero

AI is useful here, but I don't want AI to simply become a button that generates another HTTP request.

For example:

Generate a GET request for products.

That's useful.

But a more interesting question is:

Look at this API collection and help me understand how it can actually be executed.

That requires understanding:

authentication
variables
dependencies
related endpoints
potential scenarios
test cases
collection readiness

The conceptual workflow becomes:

API Collection
↓
Analyze
↓
Understand
↓
Prepare
↓
Generate Tests / Scenarios

AI becomes an assistant for understanding and preparing an API.

API Hero Prepare with AI

This idea is reflected in the Prepare with AI workflow.

Instead of exposing every technical operation as a separate action, API Hero is simplifying the experience around three user goals:

Generate Tests

Create positive and negative test cases.

Build Scenario

Create an executable workflow with dependencies.

Prepare Collection

Configure variables, authentication, dependencies, and collection readiness.

Internally, preparation can involve several steps:

Catalog API
↓
Understand structure
↓
Detect authentication
↓
Extract variables
↓
Detect dependencies
↓
Suggest scenarios
↓
Generate tests

The user doesn't need to manually orchestrate every step.

The complexity can stay underneath the interface.

OpenAPI as a starting point

Many APIs already have a machine-readable description through OpenAPI.

An OpenAPI specification can describe:

paths
HTTP methods
parameters
request bodies
response schemas
authentication schemes

That makes OpenAPI a natural starting point for API Hero.

Instead of importing a specification and simply producing:

GET /products
POST /products
GET /products/{id}

the information can become the foundation for:

OpenAPI
↓
Endpoints
↓
Schemas
↓
Authentication
↓
Variables
↓
Dependencies
↓
Tests
↓
Scenarios

OpenAPI gives us structured information.

API Hero's job is to turn that information into something developers can actually work with.

Why API Hero is a desktop application

API development rarely happens in isolation.

A typical development environment might contain:

VS Code
Terminal
Git
Browser
Database
Docker
API Client
Documentation

API Hero is being built as a desktop application to fit naturally into that environment.

The application brings together:

API requests
Collections
Environments
Authentication
Assertions
History
Collection runners
OpenAPI import
Scenarios
Dependencies
Git-oriented workflows
AI-assisted API preparation

The goal isn't to make every feature independent.

The goal is to connect them.

Building developer tools means fixing the small things too

One thing I've learned while building API Hero is that technical functionality is only half of the product.

A developer tool can have sophisticated architecture and still be frustrating if the UI gets in the way.

For example:

A generated test list needs to scroll.

A long AI preparation workflow needs to remain accessible.

A navigation sidebar shouldn't consume unnecessary workspace.

These aren't glamorous features, but they're important when a tool is used every day.

That's why API Hero 0.1.9 also focuses on desktop UX improvements:

better modal scrolling
improved handling of long content
simplified AI tools
collapsible navigation
collection workflow improvements

The objective is simple:

Make the workflow easier to use without hiding its power.

The API Hero architecture I'm working toward

The broader concept looks something like this:

             API
              │
              ▼
         Collection
              │
   ┌──────────┼──────────┐
   ▼          ▼          ▼

Variables Auth Endpoints
│ │ │
└──────────┼──────────┘
▼
Dependencies
│
▼
Scenarios
│
▼
Tests
│
▼
Automation

AI can operate across these layers:

         `    AI
              │
   ┌──────────┼──────────┐
   ▼          ▼          ▼
Analyze     Prepare    Generate
   │          │          │
   └──────────┼──────────┘
              ▼
         API Workflow`

That is the direction I'm taking with API Hero.

What I've learned building API Hero

The biggest lesson is that API testing is a workflow problem.

Sending an HTTP request is relatively straightforward.

The complexity appears when requests depend on one another.

You need to understand:

where authentication comes from
where variables come from
which request produces an ID
which request consumes it
what happens when something fails
which assertions should run
what order requests should execute in
which requests belong together
how the workflow can be automated

Once you start thinking about those relationships, an API collection starts looking less like a folder of requests and more like a graph of executable operations.

That's the problem I'm exploring with API Hero.

What's next for API Hero?

API Hero is still actively evolving.

Some of the areas I'm working on include:

better dependency detection
more reliable variable extraction
stronger assertions
richer scenario generation
API workflow automation
improved OpenAPI handling
authentication workflows
Git integration
AI-assisted API analysis

The goal isn't to create the biggest possible feature list.

It's to make this workflow increasingly reliable:

Import API
↓
Understand API
↓
Configure API
↓
Test API
↓
Connect dependencies
↓
Build scenarios
↓
Automate workflows
Try API Hero

If you're working with APIs, testing, automation, or developer tooling, I'd be interested in hearing what parts of your workflow are still unnecessarily difficult.

API Hero: https://apihero.in/

Microsoft Store: API Hero on Microsoft Store

What part of your API workflow becomes painful once you move beyond a handful of independent requests

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?