Notes from the request line.

A request can get its values from several places: a built-in default, a config file, an environment file, earlier responses, command-line flags, or a script. When two sources provide the same value, Sendra needs one clear rule for deciding which one takes effect.

Request scripts are useful when a request needs a little logic before it is sent or after a response comes back. They also create an important boundary: what should a script be allowed to reach from inside an API request file?

An exit code is useful when it tells a script what happened. Sendra keeps “the server returned an error,” “the response failed an assertion,” and “Sendra could not send the request” distinct because those outcomes call for different fixes.

What should sendra test do when an API responds with 404, but the request file never said which status to expect? Sendra leaves that response unasserted. The test command reports what the file asked it to check; it does not add a status assertion on the author's behalf.

Sendra 0.1.0 is out: the first tagged release, and the first time you can install it instead of building it from source.

Sendra is a terminal-native HTTP client. Requests are plain YAML files that live in your repo next to the code they exercise, and you send them from the shell instead of a GUI.

sendra run sends one request from your shell. sendra tui opens a full-screen terminal app for browsing and running a whole collection. They feel like different tools, but they're the same binary running the same request pipeline, and that's a deliberate design choice worth explaining, not an implementation accident.