Posting: Version-Controlled API Testing Without Leaving Your Terminal

Hook

While Postman stores your API collections in proprietary cloud formats, Posting keeps them as simple YAML files right in your project directory—finally making API requests as version-controllable as the code they test.

Context

API clients have long faced a fundamental tension: graphical tools like Postman offer convenience but trap your request collections in proprietary formats and GUI-dependent workflows, while command-line tools like curl are scriptable but lack state management and ergonomic interfaces for complex request building. For developers who work primarily in terminal environments—especially those connecting over SSH to remote development servers—this divide creates friction. You either fire up a heavy GUI application that can’t run remotely, or you maintain fragile shell scripts with hardcoded curl commands.

Posting, built by Darren Burns using the Textual framework, bridges this gap with a terminal user interface that brings the interactive experience of GUI clients into the terminal. More importantly, it stores every request as a human-readable YAML file in your local filesystem, making API collections first-class citizens in version control. For teams practicing infrastructure-as-code and seeking to version everything, this means your API testing workflow can finally live alongside your codebase in Git, reviewable in pull requests and shareable without cloud sync services.

Technical Insight

Posting’s architecture centers on Textual, a Python framework for building sophisticated terminal UIs with a reactive component model similar to modern web frameworks. This gives Posting capabilities that traditional CLI tools can’t match: keyboard-driven navigation with ‘jump mode’ (type-to-navigate functionality), syntax highlighting powered by tree-sitter, and a command palette for discoverable functionality—all rendered with rich formatting in your terminal.

The local storage model uses YAML files for request definitions. While the exact format isn’t documented in the README, the storage approach is plaintext-based, meaning you can edit requests in your preferred editor, diff them in code reviews, and track API evolution over time through Git history. The application supports environment variables and variables, enabling separation of environment-specific configuration (development, staging, production) from request definitions.

What sets Posting apart from simpler terminal HTTP clients is its extensibility through Python scripting. The README confirms you can ‘run Python code before and after requests,’ enabling programmatic request manipulation and response processing. This scripting capability appears to transform Posting from a simple HTTP client into an automation platform where you can chain requests, extract data from responses, implement custom authentication flows, or integrate with external tools—all while maintaining the interactive TUI experience.

The keyboard-centric design includes Vim key bindings and jump mode navigation. The README describes jump mode as a navigation feature, though the specific mechanics aren’t detailed. Combined with customizable keybindings, this creates workflows optimized for keyboard efficiency. For developers who spend their day in tmux or terminal multiplexers, Posting integrates seamlessly into existing window management patterns.

Interoperability is handled through strategic import/export capabilities. You can paste a curl command directly into the URL bar and Posting parses it into a structured request. Export works in reverse, letting you share requests as curl commands. The application also supports importing from Postman collections and OpenAPI specifications, enabling migration of existing API documentation without manual recreation.

Gotcha

Posting’s terminal-native design is both its strength and limitation. If your workflow depends on visual request builders or collaborative features like real-time shared collections and comments, you’ll find Posting sparse. It’s optimized for keyboard efficiency and text-based workflows, which means graphical conveniences are deliberately absent. The lack of cloud sync also means sharing collections with non-technical stakeholders requires either teaching them Git workflows or exporting to other formats.

Installation requires either uv or pipx, which may be unfamiliar to developers who typically install tools through system package managers. The README explicitly notes that Homebrew and NixOS aren’t officially supported at the moment, creating friction for teams standardized on those ecosystems. While uv handles Python version management automatically (installing Python 3.13 if needed), adding another tool installer to your system for a single application feels heavyweight compared to platform-native package managers. For teams with strict security policies around tool installation, getting approval for uv might delay adoption.

Verdict

Use Posting if you live in terminal environments, work over SSH regularly, want API collections version-controlled alongside code in Git, or prefer keyboard-driven workflows with Vim-style efficiency. It’s ideal for backend developers, DevOps engineers, and teams practicing infrastructure-as-code who value automation through Python scripting over GUI convenience. The YAML storage format makes it perfect for open-source projects where contributors need to replicate API calls without proprietary tools. Skip if you need team collaboration features like cloud-synced collections and shared workspaces, depend on GUI elements for request building, or work in organizations where installing tools via uv/pipx creates approval friction. Also consider alternatives if you require extensive package manager support, as Homebrew and NixOS aren’t currently officially supported.