Noodle keeps REST collections in YAML files beside your code

A collection is a folder of YAML, so it diffs like code

A Noodle collection is a directory of YAML files, not a proprietary workspace. Requests live in those files, folders organise them, and Git tracks them next to the service code that calls the API. That decision is what separates Noodle from the clients it imports from, where Postman and Insomnia arrive as foreign formats carrying their own script dialects.

One collection serves four consumers, and the README names all four: the TUI, the CLI, scripts, and coding agents. Nothing in the collection format belongs to the interface that wrote it, which is why a human at a terminal and a CI job can drive the same request.

The repository ships its own examples under collections/, including a scripting data run, so the on-disk shape is meant to be copied rather than designed. A change to a request shows up in a pull request as text a reviewer can read, which is the whole point of storing them as YAML.

Pre scripts, post scripts and tests inherit collection to folders to request

The scripting model is worth reading twice. Pre scripts, post scripts and tests each execute in a fixed order: collection first, then folders, then the request. Because the request sits last, a successful write at request level overrides whatever an inherited collection-level script set. One rule, stated once, removes most of the guesswork from sharing a base URL or an auth header across a hundred requests.

Scripts are JavaScript, and they run in a sandbox rather than in your shell. The dependency list names quickjs-emscripten-core 0.32.0 next to @jitl/quickjs-singlefile-mjs-release-sync 0.32.0, an Emscripten build of QuickJS. Scripts can be written inline and shared across collections and folders, or pointed at external JavaScript files.

The API those scripts call is generated rather than hand-written. package.json carries script:generate and script:check, and the build:bin chain will not compile until script:check passes alongside two more check scripts for the schema validator and the script type libraries. Authoring happens in the TUI with completion, diagnostics, folding and formatting, and the Console holds the logs.

Installation is a shell script piped from the project's own domain

Installation is one line:

curl -LsSf https://noodlerest.dev/install.sh | sh

Worth naming plainly: you are executing a script fetched from noodlerest.dev before you have read it. The other paths sit behind the installation options page, which covers Homebrew and source builds. Prebuilt binaries cover macOS and Linux on arm64 and x86_64, and the README names no Windows binary.

What gets installed is a compiled Bun binary, not a Node script. The build:bin script compiles src/app/cli.ts together with the script diagnostics worker, signs the macOS binary through scripts/sign-macos-binary.ts, and ends with a compiled script smoke test. package.json also sets "private": true and maps the bin name noodle to src/app/cli.ts, so the CLI is not installed from an npm registry: the binary, Homebrew and a source build are the distribution paths.

bun run dev takes a collection path and an environment name

Contributors run the interface from source with Bun, which the README names alongside TypeScript, React and OpenTUI:

bun install
bun run dev -- --collection ./collections --env development

Those two flags carry more weight than they look. --collection points at the collections directory and --env selects an environment, and the repository's own example run passes exactly that pair, so the development loop reads the same files as the shipped examples. The dev script is bun --watch src/app/cli.ts, which means the CLI entry point and the TUI are one program rather than two.

The dependency list explains the rest of the stack: @opentui/core, @opentui/react and @opentui/keymap for the terminal interface, citty for the command line, and react 19 for the panes. Linting and formatting are oxlint and oxfmt as package scripts, typecheck runs the TypeScript compiler from node_modules, and husky is wired to prepare.

Assertions check status, timing, headers and JSON values

Assertions live beside the request instead of in a separate test project. Both the TUI and CI check status, timing, headers and JSON values, and the scripted-test matchers cover JSON Schema draft-07 plus property, length, type and partial-object comparisons. ajv 8.20.0 with ajv-formats 3.0.1 sits in dependencies for that work, and a build script checks the schema validator is current, so a stale validator fails the build rather than passing quietly.

The collection runner adds the batch concerns: tag filters to select what runs, fail-fast behaviour, delays between requests, iteration over CSV or JSON data, and results emitted as JSON. csv-parse 7.0.2 covers the CSV side. Test data does not have to be typed by hand either, because $random and $time placeholders fill bodies with generated values and timestamps.

The glue between requests is response capture: values from one response can be passed to later requests or saved into an environment or a secret, which is how a login call feeds the rest of a run without hand-copying a token.

OAuth 1.0a, SigV4 and the cookie jar each arrive with a dependency

Authentication breadth is where package.json becomes a spec sheet. Bearer tokens, basic auth, API keys, OAuth 1.0a, OAuth 2.0, NTLMv2 and AWS SigV4 are all named in the README, and the packages line up: oauth-1.0a for the 1.0a flow, jose for the OAuth 2.0 side, aws4 for SigV4. Secrets themselves live in the OS vault, while environments switch between sets of values.

Transport has its own settings: proxy policies, custom certificate authorities and mutual TLS, which is the combination an engineer meets first when a corporate network sits between the terminal and the API. tough-cookie 6.0.2 backs a cookie jar kept per collection, so a session established by a login request is available to later requests in that collection and to no other.

Response history sits alongside all of this, so an earlier response can be reopened instead of re-sent, and the response pane previews supported images and saves binary payloads to disk.

Imports keep compatible scripts and refuse to translate the rest

Import covers OpenAPI, Swagger, Postman and Insomnia; export goes back to OpenAPI or Postman. The revealing sentence is the caveat: compatible Postman and Insomnia scripts are preserved without translating foreign APIs, and any import that retains scripts or tests has to land in a new collection.

That reads as a deliberate position rather than an oversight. Noodle will not pretend a foreign script dialect maps cleanly onto its QuickJS sandbox, so a migration either arrives as plain requests or arrives as something you finish by hand in a fresh directory. Round-tripping an existing Postman workspace therefore costs more than the import button suggests, and it costs nothing on a greenfield API where OpenAPI is the source anyway.

Coding agents get their own path:

noodle agent install

That installs the Noodle skill so an agent can create, maintain and run collections rather than only read the documentation.

Three patch releases in six days, all on a 0.x version

The repository is not archived, and the last push landed on 2026-09-30 with v0.9.6 published on 2026-09-29, v0.9.5 on 2026-09-27 and v0.9.4 on 2026-09-24. Three patch releases inside six days on a 0.x version means the interface will move under you, and CHANGELOG.md is where you read what changed.

Licensing is Apache-2.0 with nothing unusual attached, and the sponsor note states that the project is free and open source and that sponsorship pays for maintenance, bug fixes, documentation and platform testing.

The upgrade cost is visible in the dependency file. Some packages are pinned exactly, ajv 8.20.0, csv-parse 7.0.2, quickjs-emscripten-core 0.32.0, while others float on a caret, @opentui/core ^0.5.12 and react ^19.3.0 among them. A compiled Bun binary plus a Bun-based development environment puts the runtime inside the toolchain decision, and no Node-based entry point is described anywhere in the README.

Editorial conclusion

Noodle fits teams that already version their API calls and want one collection to serve a terminal, a CI job and an agent. It does not fit a team migrating a Postman workspace and expecting one-click parity, since foreign scripts are preserved or dropped, never translated. Check collections/scripting-data first to see whether the on-disk format matches how you organise services.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. wilfredinni/noodle on GitHub