I Got Tired of Switching Between curl and Postman — So I Built My Own CLI

Rushikesh Pawar — Sat, 28 Mar 2026 17:59:53 +0000

I didn’t start this project to build “another HTTP tool.”

I started it because I was frustrated.

Github : https://github.com/I-invincib1e/Httli

Every time I worked with APIs, I found myself stuck between two extremes:

curl → powerful, but painful to reuse, ugly output, hard to manage workflows
Postman → beautiful and powerful, but not scriptable, not terminal-friendly

And I kept thinking…

Why do I have to choose between these two worlds?

The Real Problem

The issue wasn’t making a single API request.

It was everything around it:

Reusing requests
Extracting values (like tokens)
Running flows (login → fetch → update)
Using it inside scripts or CI

With curl, I ended up writing messy bash scripts.
With Postman, I was clicking around with no automation.

There was no clean bridge between the two.

The Idea

I wanted something simple:

A CLI tool that feels like Postman… but behaves like curl.

That’s how Httli started.

What Httli Became

Over time, it turned into something much more than I expected.

Not just a request tool — but a workflow engine inside the terminal.

🔧 Real Example

Here’s the kind of flow I always wanted:

# Save a request
httli collection save auth/login \
  -u https://api.example.com/login \
  -m POST \
  -d @payload.json

# Run it and extract token
TOKEN=$(httli collection run auth/login -x .data.token)

# Run full workflow
httli collection run-all auth/ --fail-fast

That’s it.

No switching tools.
No messy scripts.
No manual copying.

✨ Key Features

1. JSON Output for Automation

httli request send -u https://httpbin.org/get --format json | jq '.ok'

Clean, structured output — perfect for scripts and CI.

2. Native Data Extraction

httli request send -u /login -x .data.token

No need for jq if you don’t want it.

3. Proper Failure Handling

httli request send -u /404 --fail

Exits with code 22 (like curl), making it CI-friendly.

4. Project-Based Workflows

Just create a .httli/ folder:

mkdir .httli

Now your collections live inside your project.

Share with your team
Commit to Git
Run anywhere

5. Namespaced Collections

httli collection save auth/login ...
httli collection save auth/refresh ...

Grouped automatically:

auth/
  - login
  - refresh

6. Batch Execution (run-all)

httli collection run-all auth/ --fail-fast

Run full API flows with built-in chaining:

HTTLI_LAST_STATUS
HTTLI_LAST_JSON
HTTLI_LAST_BODY_PATH

🧠 How It Evolved

This project didn’t start clean.

At first, it was:

hardcoded command handling
limited depth
basic output

Then I rebuilt the core using a recursive command walker.

That changed everything.

Now:

commands can be nested infinitely
logic is clean and modular
new features don’t break old ones

🤖 Yes, I Used AI

I’ll be honest — I used AI heavily while building this.

But not in the way people assume.

AI didn’t “build it for me.”

It helped me:

move faster
explore ideas
refine implementations

The real challenge was still:

designing the system
making tradeoffs
deciding what should exist

And honestly, that’s the part I enjoyed the most.

🚀 Why I’m Sharing This

Right now, Httli is at a stage where it’s:

stable
scriptable
actually useful

But tools only get better when people use them.

🤝 I’d Love Your Feedback

If this sounds interesting, try it out:

go install github.com/I-invincib1e/httli@latest

And tell me:

what feels good
what feels missing
what breaks

🔮 What’s Next

I’m thinking about adding:

smarter workflows
maybe AI-assisted request generation
deeper automation features

But for now, I want to focus on making the current experience solid.

Final Thought

I didn’t build Httli to replace curl or Postman.

I built it because I needed something in between.

If you’ve ever felt that gap too —
this might be useful to you.