Why Sendra
The request is the file
Every request and collection lives in your repo as plain YAML: reviewable in a pull request, diffable over time, no export step.
One binary, nothing else
The scripting engine, the test runner, and the interactive TUI all ship inside sendra. No Node.js or other runtime to install alongside it.
Terminal-native, not bolted on
Sendra isn't a GUI app with a CLI feature added later. The terminal is the whole interface, from a single request to the full TUI.
Collections & environments
A request is a YAML file: method, URL, headers, body, sent straight from the shell. Group related requests into a named collection in one file, and point the same requests at staging or production by swapping which environment loads, using {{variable}} substitution pulled from .sendra/environments/*.yaml or your shell's own environment.
Scripting & assertions
Attach a pre_request script to shape a request before it's sent, and a post_request script to check what comes back. Both are written in Rhai, with the interpreter linked straight into the binary, so a scripted request works anywhere sendra does. Add a declarative assertions: block and sendra test fails your build the moment a response doesn't match.
A full interactive TUI
sendra tui, or just sendra with no arguments, opens a real terminal UI, not a response viewer bolted onto the CLI: browse and run requests, edit every field in place, switch environments, search and filter, and open multiple collections at once in tabs. Every request's run history is one keypress away.
OAuth, built in
auth: oauth: acquires a token before the request goes out and sets the header for you. client_credentials and password grants work from any request file; the TUI adds authorization_code support with a real interactive login: it opens your browser, runs a local callback listener, and caches the token for the rest of the session.
Get started
Install with the shell script or npm, or pick pnpm, Bun, PowerShell, Homebrew, or Cargo below.