Why I Built tat: A Tiny API Test Tool for Real Integration Work and fits With AI Workflows

joehom sum — Tue, 14 Apr 2026 14:18:12 +0000

Recently, I was assigned to integrate with an API from another internal application. This was not a typical frontend-to-backend task where I could click around in a browser and verify the flow visually. It was server-to-server communication, mostly around client credentials, access tokens, request payload validation, and checking whether the API contract was still behaving the way I expected.

That kind of work sounds simple on paper. In reality, it becomes repetitive very quickly.

Every time the API changed, I had to test the flow again. Sometimes I needed to retrieve an access token using a user ID and password. Sometimes I needed to use client credentials. Then I had to call the actual endpoint, verify the input and output, and make sure nothing had silently broken before I started writing the integration code in my own application.

Of course, Postman can do this. Many teams use it. I have used it too.

But I built tat because Postman was not a good fit for the way I wanted to work.

The Real Problem Was Not "Can I Call the API?"

The problem was workflow.

When I am working on integration, I do not just want to send one request and look at one response. I want a repeatable way to prove that:

authentication still works
the request shape is correct
the API returns the fields I need
the response still matches the assumptions in my integration code
I can rerun the same checks after every API change

That is a very different need from manual API exploration.

Manual tools are useful when I am learning an API for the first time. But once the work becomes repeatable, I want something that behaves more like a test and less like a dashboard.

That was the gap tat was built to fill.

The Missing Piece: Testing the Flow, Not the Endpoint

It took me a while to realise this, but the problem was not just tooling.

It was the way I was thinking about API testing.

Most tools push you toward testing endpoints individually:

call auth endpoint
call resource endpoint
check response

But that is not how integration actually works.

In reality, I am always doing something like this:

get access token
call API A
extract an ID from the response
call API B using that ID
validate the final result

That is not endpoint testing.

That is a flow.

Flow-Based API Testing

What I actually needed was a way to test APIs as a sequence of dependent steps.

Instead of writing isolated checks, I wanted to describe a real integration journey:

data from one response flows into the next request
each step depends on the previous one
the whole sequence represents one business scenario

For example:

authenticate
list workspaces
find a specific workspace
extract its ID
use that ID to fetch related data

That is much closer to how systems behave in production.

Once I started thinking this way, the design of tat became much clearer.

tat is not just about sending requests.

It is about testing flows.

My Use Case Was Very Specific

This project came from a practical situation, not from trying to build a general-purpose API platform.

I needed a lightweight way to:

define HTTP requests in a file
inject tokens and environment values
run setup steps before tests
assert that important fields exist or match expected values
capture values from one response and reuse them in the next request
chain multiple requests into a single flow
run everything from the command line

That last point matters a lot.

I wanted a tool that fits naturally into a CLI workflow. I spend a lot of time in the terminal. My code editor, scripts, Git workflow, and AI coding assistant already live there. If my API testing tool also works well in that environment, the whole loop becomes faster.

That is why tat is JSON-driven and CLI-first.

Why Postman Still Was Not the Right Fit

To be fair, Postman is not limited to the GUI. It also has Newman and the Postman CLI, so this was never about saying, "Postman cannot run from the command line."

It can.

The issue for me was that it still was not the shape of workflow I wanted.

First, I wanted my test definitions to live as plain files in the project, in a format that was simple and purpose-built for API checks. I did not want the source of truth to revolve around Postman collections, exported artifacts, or a workspace-centric model. I wanted something easy to diff, review, generate, and keep close to the integration code.

Second, I wanted a flow that worked naturally with AI coding assistants. If I ask an agent to create a tat test for an endpoint, the mapping is very direct: generate a JSON file, add variables, assertions, captures, and run it. That is simpler than asking an agent to manage a richer collection format designed for a broader Postman ecosystem.

Third, I wanted the execution loop to stay lightweight and local.

Most importantly, I wanted the result of one request to feed directly into the next.

That is where flow-based testing really matters.

The Workflow I Wanted

The workflow in my head was simple:

Get the API details from the other team
Ask AI to generate a tat test file
Run the test from the CLI
Validate each step in the flow
Adjust until the API behaviour is fully understood
Use that verified flow to build the integration code

This is where a tiny tool is better than a large platform.

I did not need dashboards or visual flows.

I needed a repeatable execution flow.

tat gives me that.

What tat Actually Does

tat is a tiny API testing CLI where tests are written in JSON.

You define suites and tests, then run them from the terminal. A test can:

send HTTP requests
interpolate variables like {{token}}
load environment values from a file
run a setup command before tests
assert on status code, headers, body fields, and response time
capture values from a response and reuse them in later requests
chain multiple steps into a single flow
produce console, JSON, or JUnit output

That design came directly from the problem I was facing.

Try It Without Installing

If you just want to see a real flow run end-to-end before installing anything, I put together a sample project you can open directly in StackBlitz:

👉 Try tat in StackBlitz

It boots a small sample API and runs a flow against it: authenticate, call an endpoint, capture a value from the response, and feed it into the next request. No local install, no setup — just click and watch the flow pass.

That is the fastest way to feel the difference between "testing endpoints" and "testing flows."

Why CLI-Friendly Matters More Than It Sounds

When a tool works naturally in the terminal, a few good things happen:

it is easier to automate
it is easier to commit into a repo
it is easier to review changes in Git
it is easier to run in CI later
it is easier for AI coding agents to generate and execute

For flow-based testing, this is especially important.

Because flows are repeatable, they become part of your development loop, not just a one-time check.

This Tool Is Small on Purpose

I called it Tiny API Test for a reason.

I was not trying to compete with large API tools.

I was trying to remove friction from a narrow but common developer problem:

"I need to verify this API flow properly before I integrate it."

That problem appears often in internal systems.

What I Wanted From the Outcome

The real output I wanted was not just "test passed."

I wanted confidence.

Confidence that:

the authentication flow works
the data flow between APIs is correct
the assumptions in my integration code are valid

Once I can run a flow and see it pass, I can move forward with integration work much more safely.

Final Thought

Most API tools help you test endpoints.

tat helps you test flows.

Because in real systems, nothing happens one endpoint at a time.

Everything is connected.

And if your tests do not reflect that, you are only testing part of the system.

I built tat to close that gap.

Verify the flow first, then build with confidence.

DEV Community: joehom sum