Posting: a terminal HTTP client for keyboard-driven API work

The problem Posting solves for terminal-bound engineers

Postman and Insomnia assume a desktop session. If you work on a remote box over SSH, or you keep your editor and shell in one window, a GUI client forces you to leave that context, copy a request out, and paste the response back. Posting is an HTTP client built as a TUI, so it runs inside the terminal you already have open, including over SSH. The README describes it as "not unlike Postman and Insomnia" but keyboard-centric, with Vim keys, customizable keybindings, and a jump mode for navigation.

The second problem is storage. Requests are kept locally as plain YAML files, which the README says makes them "easy to read and version control." That matters when a request definition should travel with the code it exercises. A YAML file diffs cleanly in a pull request; a proprietary collection export usually does not. The intended audience is developers who already treat the terminal as their primary interface and who want their request definitions to sit in a repository rather than in an application database.

How Posting stores requests and what the TUI does with them

The architecture has two visible layers. The interface is built on Textual, the Python TUI framework, with tree-sitter for syntax highlighting and textual-autocomplete for completion. The data layer is the file system: requests are YAML, and environments and variables are part of the same model.

Posting also embeds a Python interpreter for pre-request and post-request scripts, so a request can compute a value before it is sent or inspect the response after it returns. Import and export are explicit features: you can paste a curl command into the URL bar to import it, export a request back to curl, and import from Postman collections and OpenAPI specs. The dependency list confirms the plumbing, with httpx pinned at 0.28.1 and openapi-pydantic for spec handling. The comment in pyproject.toml says httpx is pinned because Posting monkeypatches its _main.py, which is worth knowing before you try to upgrade that package independently.

Because requests are files, the natural workflow is to keep them in a project directory and let your existing tooling (git, grep, an editor) manage them. There is no server component described in the README, and no mention of a sync service.

Installing Posting with uv and sending a first request

The README recommends uv and gives the install commands for macOS, Linux, and Windows. The first block installs uv itself on macOS or Linux; on Windows you would follow the uv documentation instead. The second block installs Posting, and per the README it will also install Python 3.13 if needed.

curl -LsSf https://astral.sh/uv/install.sh | sh
uv tool install --python 3.13 posting

With that done, the command line entry point is simply the project name:

posting

If you prefer pipx, the README states that `pipx install posting` works as well. Homebrew and NixOS are explicitly not officially supported at the moment, so do not expect a formula or package to be maintained for you.

Once the TUI is open, the fastest first use is to paste a curl command into the URL bar, which the README lists as an import path. That converts an existing command into a stored request. From there you can add it to an environment, set variables, and use the command palette to find functionality without memorizing every binding. The README points to the website for the user guide and roadmap, and the repository ships a docs directory and mkdocs.yml, so documentation is maintained in-tree rather than only on the site.

Where Posting is the wrong tool

The README does not document any collaboration or sharing model. If your team needs a shared workspace where a collection is centrally published and permissions are managed, Posting's file-based approach means you are building that yourself with git and whatever access control your repository host provides. That is a real difference, not a detail.

The TUI is also a constraint. Anything that depends on a mouse, a rendered HTML preview, or a visual diff of two responses is outside what a terminal application can offer comfortably. The README lists syntax highlighting and a command palette, not a response comparison view or a graphical schema browser.

There is a packaging caveat too. httpx is pinned at exactly 0.28.1 because Posting monkeypatches an internal module, `_main.py`. Pinning an internal dependency this way means a future httpx release can require a coordinated change in Posting. If your environment forces a different httpx version, this package will conflict with it. Finally, the version history is informative: 2.9.1 carries the release note "I'm sorry I melted your CPU," which is a candid reminder that a TUI with file watching (watchfiles is a dependency) can consume resources when pointed at a large directory.

Posting against a browser-based client and against plain curl

The closest comparison is a browser or Electron client such as Postman. The difference is not features so much as where state lives. Postman keeps collections in its own application data and offers cloud sync and team features; Posting keeps them as YAML on disk and gives you no server. If you want a colleague to review a request change, Posting's model is a pull request against a YAML file. If you want a shared workspace with roles, Postman's model fits better.

The other alternative is curl itself, which Posting partially accommodates by importing and exporting curl commands. curl is scriptable and universally available, but it has no persistent request library, no environment variable management, and no interactive response viewer. Posting adds those on top of the same HTTP semantics, with httpx as the client library rather than curl's own stack. The practical split: use curl for one-off checks in a pipeline, and Posting when a request needs to be saved, parameterized by environment, and revisited.

Maintenance, upgrades, and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-03-25, which is the same date as the 2.10.0 release. The preceding releases were 2.9.2 on 2025-10-14 and 2.9.1 on 2025-09-24. That is a modest cadence rather than a rapid one, and the gap between 2.9.2 and 2.10.0 is roughly five months. Treat upgrade planning accordingly: the project is maintained, but it is not shipping weekly.

Upgrade cost is mostly Python packaging. Posting requires Python 3.11 or newer, and the README's uv command pins the tool environment to Python 3.13. Because httpx is pinned to 0.28.1 and monkeypatched, a Posting upgrade is the right moment to re-check that pin rather than assuming it moved. The dev dependency groups in pyproject.toml show pytest for tests and a Makefile with test targets, so building from source and running the suite is supported if you need to validate a change yourself.

The licence is Apache-2.0, which is permissive and includes an explicit patent grant. The repository also contains a NOTICE file, which Apache-2.0 expects downstream distributors to preserve. If you vendor or redistribute Posting, keep LICENSE and NOTICE intact. This is a description of the licence terms, not legal advice.

Editorial conclusion

Adopt Posting if your API work happens over SSH or you want requests in version control as YAML. Skip it if you need a graphical collection browser or a team-shared workspace, since the README describes a local, file-based tool. Before committing, install it with uv tool install --python 3.13 posting, open an existing Postman export or an OpenAPI spec, and confirm the import covers the auth and environment variables you rely on.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes