Autocurl: Making API Requests Readable, Reusable and Ag…

The problem I wanted to solve

As a backend developer, a good part of my last year went into two things: writing backend logic and testing it.

Writing the logic is one thing. Making sure it actually works as expected, handles different inputs correctly, and matches the requirements is another.

With AI coding agents becoming more capable, writing code has become considerably easier. But testing it is still something that requires a lot of manual work.

You need to prepare request bodies, pass different parameters, add authentication tokens, configure headers, and send requests to different endpoints to see how everything behaves.

For most backend developers, Postman is one of the obvious choices. But as your project grows, managing requests becomes another task of its own.

A backend project can have multiple modules, each with several endpoints. You have to go through the routes, understand what each endpoint expects, create individual requests, configure them, and then test everything.

And honestly, Postman felt like another heavy application I had to install and keep running just to test my APIs.

I also tried the conventional curl approach. But working with long curl commands directly in the terminal isn't always pleasant. Reading large JSON responses, debugging HTML error responses, or finding a small syntax mistake in a long command can become unnecessarily frustrating.

I wanted something that could solve both sides of this problem:

Automatically discover and generate API requests from my codebase.
Give me a simple way to read, manage, and execute those requests directly from my terminal.

That was the problem I wanted to solve with Autocurl.

How Autocurl works

The idea behind Autocurl is pretty simple.

If you've worked with compiled languages like C or Go, you'll understand the workflow. You write your code, run a command, and get an executable or some generated output.

Autocurl follows a similar idea.

You can run it from the root of your project, where it scans your codebase and generates a single index.autocurl file containing the discovered API requests.

Or, if you only want requests for a particular module, you can run it against that module's route file. For example, running it against user.routes.ts generates a user.autocurl file containing requests specific to that module.

Under the hood, Autocurl primarily uses AST-based parsing to understand your code and discover API routes. AI comes in as an additional layer for refinement or in cases where AST parsing alone isn't sufficient.

Once the file is generated, you don't need to manually edit or construct curl commands.

Simply run Autocurl again with the generated .autocurl file:

autocurl index.autocurl

You'll get an interactive terminal interface where you can navigate through the available requests using your keyboard arrows, select an endpoint, and execute it.

The interesting part is that these aren't traditional curl commands. The .autocurl file uses its own readable, pseudo-code-like format, designed to make requests easier to understand and work with.

When you execute a request, Autocurl uses Go's HTTP client underneath to send it.

So you get a readable representation of your API requests without having to deal with long, manually assembled curl commands.

Why I wanted Autocurl to be AI-agent-friendly

This is probably the part of Autocurl that interests me the most.

AI coding agents are getting better at writing backend code, but testing what they've written is still a different challenge.

Imagine having a large backend with multiple modules and dozens of endpoints. You ask your coding agent to test a particular endpoint. It might have to go through the codebase, understand the routes, figure out the required parameters, construct request bodies, add headers and authentication, and then execute everything.

It can do all of that, but the process can get messy.

I wanted to make that workflow simpler.

With Autocurl, an agent can run a single command to discover and generate API requests from the codebase. It can then read the generated .autocurl file, understand the available requests, and execute them individually.

Instead of repeatedly figuring out how to construct requests from scratch, the agent gets a readable and reusable representation of the APIs it needs to test.

And this isn't just useful for agents. Developers can use the same files to understand their APIs, inspect requests, and test endpoints without switching between multiple tools.

That's the direction I want to take Autocurl: build something that AI agents can work with naturally, while keeping the experience just as useful for the developers behind them.

What's coming next?

Autocurl is still evolving, and I'm actively working on improving it based on feedback from early users.

One of the things I'm currently working on is better authentication handling. In the next version, you'll be able to define your authentication tokens in an environment file, and Autocurl will read them directly when executing requests.

I'm also working on making request bodies and other data configurable directly through .autocurl files, so you don't have to keep modifying generated requests manually.

There are quite a few other improvements on the list as well. Some of them came directly from conversations with people who have already tried Autocurl.

I don't want to rush these features just to have a longer feature list. I'd rather make the workflow genuinely useful and get the fundamentals right first.

There's still a lot to build, and I'm looking forward to seeing how developers use it and what they would like to see next.

Give Autocurl a try

Autocurl started as a problem I wanted to solve for myself as a backend developer. Now I want to see how useful it can be for other developers and people building with AI agents.

If you work with APIs, build backend services, or experiment with AI coding agents, I'd love for you to give it a try.

You can check it out at autocurl.lol.

I've also listed Autocurl on Product Hunt and Peerlist. You can check out the projects there and share your thoughts.

If you have feedback, feature suggestions, or think there's a better way to approach something, feel free to reach out to me at [email protected] or leave a comment on either project page.

I'm building this in public, and feedback from people who actually use it makes a big difference.

Thanks for reading!