Why I Built a Local-First HTTP API Client

Let me start with the part that might sound odd coming from someone who built one: the HTTP API clients you already know are excellent.

They are polished, fast and deep. They handle every authentication scheme you can think of, they have mock servers, monitors and documentation generators, and they let a whole team share one workspace in real time. For a company with dozens of developers working on the same set of APIs, that is exactly what you want, and they do it very well.

I am not a company with dozens of developers. I am one person, and most of the time I just want to send a request, look at the response and move on. So when I looked at what I actually needed from an API client, it turned out to be a much shorter list, with one item on it that the big tools are not built around.

The one requirement: my data stays on my computer

An API client sees more sensitive material than almost any other tool on a developer’s machine.

Think about what sits in a typical collection. Bearer tokens and API keys. Internal hostnames that are nobody else’s business. Staging credentials. Request bodies built from real records while you debug something that only fails with real data. Responses full of personal information that came back from a production endpoint at two in the morning.

Modern API clients are, quite reasonably, built around an account and a cloud workspace. That is what makes team collaboration work: your collections live on a server, so your colleagues can see them. Most of them let you limit what is synced, and many of them take security seriously. But the default shape of the tool is still “sign in, and your work lives with us”, and I kept finding myself working around that rather than with it.

I did not want to have to think about which variables were marked secret, which workspace was synced, or whether a response I pasted into a request body had just left the building. I wanted the simplest possible guarantee: nothing leaves my computer except the requests I choose to send.

No account just to send a request

The second thing was smaller, but it bothered me every day.

Sending an HTTP request is about the most basic thing a developer does. It should not need a login screen, a session that expires, or a network connection to a service that has nothing to do with the API I am testing. I wanted to open the app on a train with no signal and still have every collection, environment and piece of history right there.

Plain files I can read, back up and version

Once the data stays local, the next question is what shape it is in.

I wanted my workspaces to be ordinary folders and my collections to be plain JSON files. Files I can open in any text editor, copy to a backup drive, search with the tools I already use, and keep under version control right next to the code that calls the API. When a request changes, I want to see that change in a diff, not trust a sync status icon.

That also means no lock-in. If I stop using the app tomorrow, my work is still sitting there in a readable format.

Without throwing away what I already had

The obvious risk with building your own tool is ending up with a blank slate and years of saved work stuck somewhere else. That was a deal-breaker for me, so it shaped the whole design of FlosForge Caller:

It opens the collections and environments I already had. Export them from your current client, drop the files in, and folders, requests, bodies, auth, variables and scripts come across. An import summary tells you about anything that needs a manual look.
The scripts still run. Pre-request and test scripts written for the familiar scripting API work without being rewritten, and test results appear right beside the response. Scripts run in an isolated worker that cannot touch your files.
Pasting a request copied from the terminal turns it into a request in the app, so moving something over from a shell session takes a second.
Whole collections run from the command line too, with the same engine as the app, so the same tests can run in a CI pipeline and fail the build when something breaks.

On top of that I added the things I personally kept wishing for: captures that pull a value out of a response into a variable without writing a script, flows that chain requests into a sequence like “log in, create an order, poll until it is paid”, and a connection timeline that shows exactly where the time went, from DNS to the last byte.

What it deliberately does not do

Building for one person means saying no to a lot.

There are no hosted mock servers, no scheduled cloud monitors and no team workspaces, because each of those needs a server somewhere, and the whole point was not to have one. A few less common authentication schemes are not supported yet either. If your work depends on those, the big tools are the right choice, and I would honestly recommend them.

Like most of what I publish, Caller started as something I built for myself. It became the tool I reach for every day, and it seemed a shame to keep it on my own laptop when other people might want the same thing: a capable API client that never asks who you are and never takes your data anywhere.

So it is free and open source, under the GNU GPL v3. There is no paid tier, no account and nothing to buy. It is a personal project, offered as it is, in the hope that it is useful to someone else too.