# slumber: a terminal HTTP client where the config is the source

> Slumber is a terminal user interface for HTTP and REST work whose defining choice is that requests live in YAML files you can commit, so a collection of request recipes is reviewable, shareable and scriptable. It can be driven as a TUI, as a command line tool, or as a Python package, and the project states its principles plainly, including a promise that it will remain free to use forever.

**LucasPickering/slumber** — Terminal-based HTTP/REST client

- Repository: https://github.com/LucasPickering/slumber
- Website: https://slumber.lucaspickering.me/
- Stars: 1,229 · Forks: 40
- Language: Rust
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/lucaspickering-slumber

## Source first configuration

Slumber is a TUI, a terminal user interface, HTTP client, and the README states the principles it is built on. It will remain free to use forever, you own your data, because all configuration and data is stored locally and can be checked into version control, and it will never be enshittified.

That middle principle is the design. Most HTTP clients store their requests in a proprietary document, in a local database, or in an application's own format, and sharing them means exporting a file that the other person has to import. Slumber inverts that. The requests are the source, in a text format, and the tool is a way to execute them.

The consequences run through the whole feature list. Source-first configuration is described as being for easy persistence and sharing, and it is what makes the other features possible rather than an extra. You can import from external formats, for example Insomnia, which suggests the author expects people arriving with collections written somewhere else. You can build requests dynamically from other requests, from files and from shell commands. You can switch between environments with profiles. And you can browse response data with JSONPath selectors.

So the audience is not a person exploring an unfamiliar API in a browser. It is a developer who already has an API and wants a request collection that lives next to the code, that a colleague can open, and that a script can consume.

## Collections of recipes, written as YAML

The data model is small and it is worth understanding precisely, because the words are reused in a particular way.

Slumber is based around collections. A collection is a group of request recipes, and a recipe is a template for the requests you want to run. So a recipe is not a request, it is the thing a request is made from, and the environment specific parts, the URL, the headers, the body, are filled in when it is run.

The example is a file called slumber.yml, and it contains a requests map with a get entry and a post entry:

```yaml
# slumber.yml
requests:
  get:
    method: GET
    url: https://shoal.lucaspickering.me/fish

  post:
    method: POST
    url: https://shoal.lucaspickering.me/fish
    body:
      type: json
      data:
        {
          "name": "Barry Bartlett",
          "species": "Barracuda",
          "age": 3,
          "weight_kg": 6.2,
        }
```

Create this file, then run the TUI with slumber. The body is a structured value with a type of json and the data itself as a mapping, rather than a string, which is what allows the templating features to reach inside a request body rather than only inside a URL.

The repository itself carries a slumber.yml at the top level, which is the collection the project uses for its own testing, alongside a test_data/ directory and a schemas/ directory. The schemas are the JSON Schema for the configuration format, and they are generated with the schemars crate, which is why that crate is in the dependency list. That means your editor can validate a slumber.yml as you type it, and the format is defined once rather than described in prose.

## TUI, CLI and a Python package from one core

The first feature on the list is that Slumber is usable as a TUI, as a CLI, or as a Python package, and that triple is the reason the project is worth looking at even if you never open the terminal interface.

The TUI is the interactive part, and the README shows it as an animated demo. The topic list includes ratatui, the Rust TUI framework, which is what the interface is built with, and the repository has a tapes/ directory, which in this ecosystem means recorded terminal sessions used as tests. That is a notable testing choice: a terminal interface is hard to test, and recording the interaction as a tape makes the interface itself testable.

The CLI is the same core driven by arguments, and the package manifest shows a slumber_cli crate wired into the workspace with a path dependency, so the command line layer is a separate crate rather than a mode inside the binary.

The Python package is the one that surprises people. Slumber can be driven from Python, which means an HTTP collection defined in YAML can be invoked from a script or a test in another language. For a team with an API described in one place and tests written in Python, that is the interesting part of the tool, and the project links a dedicated page for it.

The dependencies explain the rest. reqwest is the HTTP client, clap 4.4.2 is the argument parsing, serde and serde_yaml are the configuration layer with serde_json configured to preserve order, and serde_json_path 0.7.1 is the JSONPath implementation behind the response filtering.

## Profiles, templates and JSONPath responses

Three of the features do real work and are worth describing in terms of what they let you do.

Profiles are the environment switch. The README lists switching between different environments easily using profiles, and there is a whole API page for the profile concept. In a request collection that lives in version control, the URL and the credentials for staging and for production cannot both be in the same file, and profiles are how the file stays one file while the environment is a choice at run time. The repository has a slumber.yml of its own, which is presumably where the project's own profile configuration lives.

Templates are the composition mechanism. Requests can be built dynamically from other requests, from files and from shell commands. That is what makes a collection more than a list of URLs. You can take a value out of the response to a login call and put it into the next request, you can take a payload from a file in the repository, and you can call out to a command on your machine to produce a value. A collection that can do that is a script that happens to be written in YAML.

JSONPath is the response side. You can browse response data using JSONPath selectors, which is how you read a field out of a large response without scrolling, and it is the natural counterpart to the templating, since the value you select in one response can be the value you template into the next request.

The chain of these three is the actual workflow. Execute a request, select a value from the response, feed it into the next request, run that under a different profile. That is a test script and a debugging tool at once, and it is why the file format is designed to be diffable.

## The workspace layout and the test tooling

The Cargo.toml describes a workspace with the root package and a crates/ directory of subcrates, and the shared metadata in the workspace.package section:

```toml
[workspace.package]
authors = ["Lucas Pickering <lucas@lucaspickering.me>"]
edition = "2024"
homepage = "https://slumber.lucaspickering.me"
keywords = ["rest", "http", "terminal", "tui"]
license = "MIT"
repository = "https://github.com/LucasPickering/slumber"
version = "5.4.0"
# Keep in sync w/ rust-toolchain.toml
rust-version = "1.90.0"
```

The comment about keeping rust-version in sync with rust-toolchain.toml is the kind of detail that shows the project is pinned deliberately rather than by accident, and a rust-toolchain.toml at the repository root is what makes a contributor's checkout use the same compiler.

The test tooling in the dependency list is unusually rich for a terminal application. rstest is the test framework, proptest and proptest-derive are for property based testing, pretty_assertions and serde_test are for the data layer, and saphyr is a YAML parser, and serde_yaml is also present at 0.9.0.

The repository layout backs this up. There is a.rules directory, a.clippy.toml and a.rustfmt.toml for linting and formatting, a mise.toml with a mise-tasks/ directory for task running, a RELEASE.md for the release process, a CHANGELOG.md, and a docs/ directory that holds the user guide and the pages the README links to, including the Python integration page and the import page.

## Where Slumber is the wrong tool

The limits follow from the design, and the design is opinionated in a way that is easy to admire and easy to over-apply.

The first is that the configuration is local and the tool has no server. The README says you own your data because all configuration and data is stored locally and can be checked into version control, and the tool is a client that executes requests. There is no shared workspace, no team server, no account, no permissions and no audit trail. For an individual or a small team that commits their collection to a repository, that is exactly right. For a larger organisation that wants one shared catalogue of internal APIs with access control, this is not that product.

The second is the price promise. The project states it will remain free to use forever and will never be enshittified, and the release history supports the first half of that, with 5.2.5 in April 2026, 5.3.0 in May and 5.4.0 in October. It is a credible statement from a single maintainer, and it is still a statement by a person rather than a guarantee.

The third is that the TUI is the centre of gravity. A terminal interface is a real interface with real ergonomics, but it is a different way of working from a browser based client, and the learning curve for a colleague who has never used one is not zero. The CLI and the Python package exist for exactly that reason, and they are the more scriptable entry points.

The fourth is that a file based collection is only as good as the schema and the tooling around it. The project has JSON Schemas for the configuration and the formats are plain YAML, so this is a strength rather than a weakness, but it does mean the collection is not a place to store things YAML should not hold, and a collection with credentials in it is a collection you do not commit without thinking.

## Conclusion

Adopt slumber if you keep an API collection that other people need to see, if you want requests in version control next to the code that uses them, or if you want to drive HTTP from a script or from Python without a GUI in the loop. Do not adopt it if you need a shared team server for HTTP requests, since the configuration is deliberately local, and do not adopt it if you want a browser developer tools panel. Verify first that your toolchain is on Rust 1.90 or newer, that the profiles and template features match how you switch environments, and that the Python integration page describes the interface you need before you build on it.

## FAQ

### What is Slumber and how do I start using it?

Slumber is a terminal user interface HTTP client. You define requests in a YAML collection file, for example a slumber.yml with a requests map, and then run the TUI with the slumber command. The full documentation is at slumber.lucaspickering.me.

### Can I use Slumber from a script or from Python?

Yes. The README lists being usable as a TUI, as a CLI, or as a Python package, and the project links a dedicated Python integration page. The workspace also contains a separate slumber_cli crate for the command line layer.

### How do I switch between environments in Slumber?

With profiles, which the README lists as a way to switch between different environments easily, and which have their own page in the API documentation. The request collection stays one file in version control and the environment is chosen at run time.

### Can Slumber import requests from another client?

Yes, the README lists import from external formats, with Insomnia given as the example, and links the import page in the user guide.

## Sources

- [License: MIT](https://github.com/LucasPickering/slumber/blob/master/LICENSE)
- [LucasPickering/slumber on GitHub](https://github.com/LucasPickering/slumber)
- [Project website](https://slumber.lucaspickering.me/)
- [README](https://github.com/LucasPickering/slumber/blob/master/README.md)
- [Releases](https://github.com/LucasPickering/slumber/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lucaspickering-slumber