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

This project started when a friend got a freelance job. He was handling the mobile app, and he asked me to help by building the backend API side.

That meant we needed a practical way to communicate around the API contract: endpoints, authentication, request payloads, and expected responses. Even though he was building the mobile app and I was working on the backend API, we still needed a reliable way to verify authentication flows, payload validation, and whether the API still behaved the way we expected as it changed.

At first, we used Postman.

That sounds reasonable, and for simple exploration it was fine. But when both of us needed to keep the same API definition in sync, the workflow became awkward very quickly. If you want to use Postman's team collaboration features properly, you need to pay. So we went with the cheaper method: export the collection, send it over, then import it again on the other side.

In practice, that was painful.

Every time the API changed, we had to repeat the same handoff. Collections drifted. It was hard to tell what had changed. Re-importing was tedious. And once authentication and dependent requests were involved, it became even harder to verify the whole flow cleanly.

Very quickly, I started thinking: instead of passing collections around, why not build a lightweight, file-based API client tool that both of us could understand, diff, and run easily?

That idea was the starting point. But while building it, I realised the deeper problem was not just sharing API requests. It was testing the whole integration flow properly.

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:

1. get access token
2. call API A
3. extract an ID from the response
4. call API B using that ID
5. 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:

1. Get the latest API details and expected behaviour
2. Ask AI to generate a tat test file
3. Run the test from the CLI
4. Validate each step in the flow
5. Adjust until the API behaviour is fully understood
6. 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.

Links

• 🚀 Try tat in StackBlitz (no install): https://stackblitz.com/github/nanotinydev/tat-sample-api?file=README.md
• 📦 npm: npm i -g @nanotiny/tiny-api-test
• 🛠 GitHub: https://github.com/nanotinydev/tat
• 🌐 Website: https://nanotinydev.github.io/tat/