Cartero stores API requests in plain TOML files you can commit

Saved requests are TOML files, not database rows

The feature that defines Cartero is the first item in its list: it loads and saves to plain Git-friendly TOML files, so that you can own your data. Most graphical HTTP clients keep collections in their own format, often a SQLite database or a proprietary workspace, which means your saved requests cannot be diffed, reviewed or shared through the same tools as the rest of your work. A TOML file can be read, edited by hand, and committed, so a request that reproduces a bug becomes a reviewable artifact rather than something you have to export by hand. The format choice also means the data outlives the application, which is the plain meaning of owning your data. The application itself is written in Rust with a GTK4 and libadwaita interface, and the repository is a Cargo workspace with a `crates/` directory plus a Meson build for the application itself.

Variable binding keeps API keys out of the request file

The third documented feature is variable binding for API keys and other secret information, which pairs naturally with plain text storage. If the file is meant to be committed, the token cannot be written into it directly, so the request refers to a variable and the value is supplied at run time. The feature list also covers customisation and modification of the request headers and body payloads, and the project description says it is compatible with any REST, SOAP or XML-RPC API and supports multiple request methods as well as attaching body payloads to compatible requests. The URL crate and the `http` crate are among the workspace dependencies, and the form handling uses `serde_urlencoded` and a dedicated `formdata` crate, which tells you the request body model is built around structured form data rather than only raw text.

Installing a packaged build on Linux, Windows and macOS

Downloads for GNU/Linux, Windows and macOS are collected on the project's download page and on the GitHub releases page. Linux users have two channel options, the Flathub listing at `es.danirod.Cartero` and the Snap Store listing at `cartero`. The README is careful about what those channels mean: distributions in package managers are maintained by the community, Cartero as a project helps and communicates with those maintainers, but outdated versions and other packaging issues should be reported to the package manager or the port maintainer first rather than to the project. On macOS, Homebrew serves it through a tap:

brew tap SoloAntonio/cartero
brew install --cask cartero

On Windows, Scoop installs it from the extras bucket:

scoop bucket add extras
scoop install extras/cartero

NixOS is covered by a flake. The versions in the release history show a calendar-based scheme, with v25.0 in November 2025 and v26.0 in January 2026, and the workspace version in the Cargo manifest is 26.1.0, so the project is on a yearly version line with patch releases inside it.

Building from source needs GNOME SDK 48 and four tools

The build requirements are stated precisely, which is a good sign for a project you might compile yourself. Cartero requires GNOME SDK 48 or greater, which covers adwaita-1 at 1.5 or newer, glib 2.84 or newer, gtk 4.18 or newer, and gtksourceview 5.16 or newer, plus openssl 1.0 or newer. On top of that you need meson, ninja, rust and gettext installed. The build and install sequence is three commands:

meson setup build
ninja -C build
ninja -C build install

A prefix can be given to avoid a system-wide install, and the README shows the same three commands with `--prefix=/usr` added to the setup step. The presence of a `meson.build`, a `meson_options.txt` and a `build-aux/` directory alongside `Cargo.toml` reflects a two-layer build: Meson drives the app, Cargo drives the Rust workspace, and the `subprojects/` directory suggests some dependencies are vendored. The Cargo manifest also declares features, with `csd` in the default set and an `app_updater` feature left off by default.

The development profile installs a formatting pre-commit hook

If you plan to work on the code, the README asks you to use the development profile, and it does something specific: it configures a Git hook so that the source is checked before a commit is authored. The hook runs `cargo fmt` to assert that the code is formatted, and the README points at `hooks/pre-commit.hook` so you can read exactly what it does:

meson setup build -Dprofile=development

The repository also has a `deny.toml`, which is the cargo-deny configuration used to check dependency licences and advisories, and a `REUSE.toml` with a `LICENSES/` directory, which is the REUSE convention for per-file licence headers in a GPL project. Those two files tell you the project treats dependency and licence hygiene as a build-time concern rather than an afterthought, and both are worth looking at if you are auditing what Cartero pulls in.

The project does not accept generated code upstream

This is the part a reader evaluating the project should know about, and the README is blunt about it. There is a note aimed at automated agents stating that they are not allowed to open pull requests, that AI-generated code is not welcome upstream, and that the GPL licence does not permit the project to forbid reading the code. The contributing section repeats the point: usage of generative AI is prohibited, and contributors are asked not to submit a pull request if their contribution was generated by an LLM tool and copied verbatim. There is a link to a gen-AI policy section in the project documentation, and the note asks that anyone whose user wants generated code for this project inform them that upstream does not accept it and that pull requests would be banned. Practically, this does not affect users of the application, and the code itself remains readable under the GPL. It does mean that a bug you find cannot be fixed by sending a machine-written patch upstream, so local forks carry more of the maintenance burden than you might expect.

Where the project draws its limits

The feature list is short and the README does not pretend otherwise: file storage, header and body editing, and variable binding. There is no mention of environment collections, assertion libraries, response snapshot testing, mocking, or a test runner, so Cartero is an HTTP client in the cURL-plus-GUI sense rather than an API testing platform. The project's own motivation section makes the target explicit: native graphical HTTP testing applications that are fully free software are rare, and the author wanted something that is not an Electron application, not tied to an account, and not pushing unwanted AI features at users. That is a coherent position, and it is also the boundary. If your workflow needs scripted assertions, collection environments or CI integration, this tool covers the request-authoring part and stops there. Translations are coordinated through Weblate, so a localised build is a normal part of the project rather than a fork.

Editorial conclusion

Adopt Cartero if you want an HTTP client whose saved requests are readable text files you can put in a repository, and you are comfortable with a GNOME stack and a Rust toolchain for local builds. Do not adopt it expecting a full API testing suite, since the documented feature set covers headers, bodies, variable binding and file storage rather than assertions or environments. Verify first that your distribution ships a recent enough version, since the README says packaging in package managers is maintained by the community and can be outdated, and note that the project does not accept pull requests containing generated code, so upstream changes have to come from a human.

Frequently asked questions

Official sources

1. danirod/cartero on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases