What "0.1.0" means here​

Nothing in this release is new relative to what's been in the repo — it's the same request/collection model, CLI, and TUI introduced and described in depth in the last two posts. What changes is that it's now built, checksummed, and published under a version number, with prebuilt binaries and package-manager entries instead of a git clone + cargo build.

What's in the box​

• Requests and collections as plain YAML — method, URL, headers, and a body as body, json, body_file, form, or multipart, with auth: bearer/basic/api_key.
• sendra run and sendra test — send a request or collection from the shell, or run it against assertions: and fail the build on a miss. test supports --junit for CI report output.
• Assertions on status, headers, and body, including JSON-path checks and an operator sub-language (greater_than, matches, not:, and more).
• Capture and chaining — pull a value out of one response (JSON path, header, or status code) and substitute it into a later request in the same run.
• Environments and variables — .sendra/environments/*.yaml resolved via --env, with {{variable}} and ${OS_VAR} substitution.
• Config, layered — .sendra/config.yaml for default headers, timeout, redirects, TLS, proxy, and cookie-jar settings, resolved project-over-global, overridable per-invocation with flags like -H, --var, --insecure, --proxy.
• Scripting — pre_request/post_request hooks in an embedded scripting language (Rhai), with no external runtime to install.
• OAuth — an authorization_code login flow for requests that need a browser-based token first.
• sendra import curl, sendra init, and sendra schema — convert a curl command into a request file, scaffold a new .sendra/ project, and emit JSON Schemas for editor tooling.
• The TUI (sendra tui, or a bare sendra) — the full-screen terminal app covered in the last post, built on the same core as the CLI.
• One binary. sendra-cli and sendra-tui build into a single sendra binary — installing it gets you both.

Install it​

Shell:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/sendra-lab/Sendra/releases/latest/download/sendra-cli-installer.sh | sh

PowerShell:

powershell -ExecutionPolicy Bypass -c "irm https://github.com/sendra-lab/Sendra/releases/latest/download/sendra-cli-installer.ps1 | iex"

npm:

npm install @sendra-lab/sendra

pnpm:

pnpm add @sendra-lab/sendra

Bun:

bun add @sendra-lab/sendra

Homebrew:

brew install sendra-lab/tap/sendra-cli

Cargo:

cargo install sendra-cli

Or download a prebuilt binary directly from the v0.1.0 release page, which also has checksums for every artifact.

Once it's on your PATH:

cat > get-request.yaml <<'EOF'
method: GET
url: https://httpbin.org/get
EOF

sendra run get-request.yaml

From there, the docs cover the full request/collection schema, every CLI flag, and the TUI's keybinding reference.

Why Sendra exists​

Most HTTP client tools ask you to leave your editor and your repo behind: a separate app, a proprietary export format, requests that live in someone's cloud workspace instead of version control. Sendra starts from the opposite assumption — a request is a file. It belongs in your repo, gets reviewed in a pull request like any other change, and diffs over time the same way your code does.

A request or collection file is checked against variables from an environment file, so the same request can point at staging or production without touching the file itself. It can also declare what the response should look like — status, headers, body shape — which sendra test then passes or fails your build on. No separate assertion library, no glue script: the check lives in the same YAML as the request it's checking.

What's in the box today​

Sendra ships as a single binary. There's no separate install step for a scripting engine, a test runner, or a UI — building or installing sendra gets you all of it:

• sendra run sends a request and prints the result.
• sendra test runs one or a whole collection and fails your build on unmet assertions.
• sendra tui — or just sendra with nothing else on the command line — opens a full-screen terminal UI for browsing and running requests interactively, built directly on the same request model, YAML loading, environment resolution, and HTTP execution the CLI commands use.

The CLI side has been usable for a while: run and test requests, assert on status/headers/body, capture a value out of one response and chain it into the next request, layer config → environment → CLI overrides in a predictable precedence order, and run pre_request/post_request scripts in a sandbox with no filesystem or network access.

What's new is that the TUI has caught up past "browse and run" into a genuinely complete editor. From inside the TUI you can now:

• Edit any part of a request in place — method, URL, headers, body, auth, assertions, captures — with a form that refuses to save on an invalid method or unparsable JSON body, and discards cleanly on Esc.
• Work across multiple collections at once, each open in its own tab with fully independent selection, run state, and edit session.
• Log into OAuth authorization_code flows interactively — the TUI opens your browser, runs a local callback listener, and caches the token for the rest of the session, the same as client_credentials/password tokens are.
• Browse in-session run history per request, up to 20 runs deep, without anything touching disk.

None of this is a second product bolted onto the CLI. The TUI reuses sendra-core directly — the same request model the CLI commands run on — with one deliberate, documented gap: pre_request/post_request scripts don't run from the TUI. Everything else behaves identically whether a request is sent from a shell command or a keypress.

Try it​

There's no packaged release yet, so building from source is the way in:

git clone https://github.com/sendra-lab/Sendra.git
cd Sendra
cargo build --workspace --release
./target/release/sendra run examples/get-request.yaml

From there, the docs cover the full request/collection schema, every CLI flag, the TUI's complete keybinding reference, and the design rationale behind the harder calls — like why sendra test ignores an unasserted status, or how the sandboxing guarantees around scripts work.

This is the first post on this blog, and we're planning to use it for release-note-style updates too (tagged changelog) rather than standing up a separate changelog page — see the tag description for why.

Why "one binary" is a constraint, not a slogan​

It would have been easier, in some ways, to ship the TUI as a separate crate with its own copy of request loading, environment resolution, and HTTP execution. Instead, sendra tui reuses the same core the CLI commands run on directly: the same request model, YAML loading, environment resolution, capture logic, and HTTP execution that run/test use. There's no translation layer between "what the CLI does" and "what the TUI does" — there's one implementation, and two front ends that drive it.

That has a concrete payoff: a request behaves identically whether it's sent with sendra run request.yaml or by pressing Enter on it in the TUI. Environment substitution, config header merging, auth resolution, query and body resolution, assertions, capture — all of it is the exact same code path. If sendra test and the TUI ever disagreed about whether a request passed its assertions, that would be a bug, not an edge case to document.

The one honest gap​

There's exactly one place the two front ends diverge: pre_request/ post_request scripts don't run from the TUI. Everything else about a request's send pipeline is shared, but scripts are the one part that isn't — and it's called out as a deliberate, documented gap rather than something that quietly doesn't work. If you're relying on a pre_request script to set something up, sendra run/sendra test are still the way to send that particular request.

The TUI's editing surface has a handful of gaps drawn the same way. Only json: path assertions get a row editor — every other assertion kind (status, status_in, headers, body_contains, body_matches, elapsed_ms_under) is preserved exactly as loaded when you edit a request, but has no in-app editor yet. A body_file body is shown read-only because it names a file some other tool may have open; form/multipart bodies are read-only because they're structured, list-of-parts bodies that would need their own dedicated editor. In each case the choice is to be visibly read-only rather than silently drop or mangle something the editor doesn't fully understand.

What "complete" ended up meaning for the TUI​

Early on, the TUI's job was narrower: load a collection, list its requests, run whichever one you selected. Getting from there to something you could actually work in all day meant three things landing together:

In-place editing of a full request. i opens any selected request in an edit form — method, URL, headers, body, auth, assertions, captures — that mirrors the shape of the YAML itself. Auth editing is scoped deliberately: the editor only edits an auth block that already exists on the request, never introduces a new auth type where there was none. Saving is guarded — an invalid method or a json: body that doesn't parse as JSON blocks the save with the problem shown, rather than writing something broken back out.

Multiple collections open at once. o opens another collection as a new tab, and each tab is a fully independent session — its own selection, run state, edit session, environment, and run history, none of it bleeding into any other tab. This matters more than it sounds: without it, working across a "staging" collection and a "webhooks" collection in the same sitting meant either two terminal windows or closing one to open the other. Closing the last remaining tab resets it to the welcome screen instead of leaving you with zero tabs — there's always somewhere to land.

Interactive OAuth for the one grant type that needs a browser. client_credentials and password grants can fetch a token from fields alone — client ID, secret, token URL, nothing else required. authorization_code can't, because it needs a real human clicking "allow" in a real browser. For that one case, Ctrl+l inside the auth editor opens your browser to the configured authorization URL, runs a local callback listener bound to the configured redirect URI, waits up to five minutes for the provider to redirect back, and exchanges the resulting code for a token. That token is cached in memory for the rest of the session, and every later run of a request sharing that oauth: config reuses it automatically — including, as a side effect, client_credentials/password tokens, which get the same in-session caching even though they didn't need the browser step to get there.

The bare sendra command​

One small detail worth calling out: a bare sendra, with no subcommand at all, launches the TUI with nothing preloaded — the same as sendra tui. This was a deliberate choice, not a fallback for a missing argument. Typing just sendra is meant to be a reasonable way to start, the same way you'd type git status or htop without needing to remember a flag first. From there, the welcome screen looks for .yaml/.yml files sitting directly in the current directory and offers them as a picker, or gives you o to type a path if nothing's nearby.

None of this — the shared core, the documented gaps, the bare-command launch — reads as exciting on its own. Taken together, it's the difference between a TUI that happens to exist next to the CLI, and one that's actually the same tool wearing a different interface.