API clients in 2026: revisit Bruno, Hoppscotch and Insomnia before you save another production token in a shared collection

Most backend teams have lived this week at least once. A new joiner asks for “the collection”. Someone exports a JSON file from a shared Postman workspace and drops it in the team chat. The file has a production bearer token inside an environment, because that was the quickest way to debug an issue last month. Two weeks later half the team is on an old copy. When a teammate cannot reproduce a failing call, the answer is “send me your environment”, which means sending more secrets.

The API client is not the problem here. The problem is that we treat it as a small GUI for sending requests, when it is actually the place where environments, secrets and the team’s working knowledge of an API live.

This post revisits three open-source API clients that answer those questions differently: Bruno, Hoppscotch (the project that started as Postwoman) and Insomnia (owned by Kong since 2019). Postman is the status quo we compare against, not a fourth product under review.

The short version

• Bruno: MIT licence, built by the Bruno team (copyright Anoop M D, Anusree P S and contributors since 2022). A desktop app that stores every collection as plain files in a folder you choose, in the older .bru markup or the newer OpenCollection YAML. There is no cloud sync and the README says there are no plans to add it. Paid Pro, Ultimate and Enterprise editions add in-app Git push, secret manager integration and licence administration. Best fit when you want collections reviewed in pull requests, next to the code.
• Hoppscotch (formerly Postwoman): MIT licence for the open-source code, which is also the self-hosted Community Edition. A web app first, with desktop apps and a CLI, backed by a server that keeps workspaces in Postgres. Hoppscotch Cloud has paid plans, and the self-hosted Enterprise Edition is open-core. Best fit when you want a shared, browser-based team workspace but must keep the data on your own servers.
• Insomnia: Apache-2.0, in the Kong/insomnia repository. A desktop app with three storage choices per project: Local Vault, Git Sync and Cloud Sync (optionally end-to-end encrypted). An account is needed for everything except the local Scratch Pad. Best fit when you want design, mocking and testing in one app and are fine with a Kong account.

What the job actually is

Before comparing tools, split “API client” into the questions that matter in a security or platform review.

• Where collections live. Plain files in a Git repository, a vendor cloud database, a self-hosted server database, or local app storage on one laptop. This decides who owns the data and how you back it up.
• How secrets and environments are stored. Is a secret value written into a file that can be committed or exported? Is it synced to a server? Is it kept only on the user’s machine, or fetched from a real secret manager at run time?
• How a change gets reviewed. A pull request with a diff that a reviewer can read, or an edit inside a shared cloud workspace that is visible only in an activity log, if at all.
• Desktop, browser or CLI. A browser client is easy to roll out, but private network APIs need a proxy, agent or desktop app. A CLI runner decides whether the same collection can run in CI.
• Self-host or vendor cloud. Some teams cannot put request data or customer identifiers into any third-party cloud.
• Licence, account and paid line. Read what the open-source part covers, whether an account is required, what telemetry is on by default, and which features sit behind a paid plan.

A small Indian example

Take a payments team of six in Hyderabad. They call a partner bank’s sandbox and production APIs, an internal ledger service and a GST invoicing service run by another team. Today they share one Postman workspace. The bank’s client secret, a signing key reference and a production admin token all sit in a “prod” environment that every member can open. The security team has asked two questions for an upcoming audit: who can see the production credentials, and what changed in the collection before last month’s settlement incident. Neither question has a clean answer today.

Bruno: collections as files, reviewed like code

History and licence. Bruno lives at usebruno/bruno on GitHub. The repository was created in late September 2022 and the licence file is MIT. The README says most features are free and open source, with paid versions on top. The current pricing page lists Open Source at no cost, plus Pro, Ultimate and Enterprise plans billed per user, annually. The older “Golden Edition” name does not appear on that page now. The latest stable release at the time of writing is v4.3.0, published on 22 October 2026 (5:41 PM IST).

How it works. Bruno stores a collection directly as a folder on your file system. Each request is a file. Older collections use Bru, a plain-text markup created by the project. From Bruno 3.0.0 you can save requests as YAML that follows the OpenCollection specification, and from v3.1.0 new and imported collections use YAML by default. A collection cannot mix the two formats, and the in-app migration from .bru to .yml needs v4.1.0 or later. Collaboration happens through Git or any version control you already use. The free app includes basic Git actions such as init, clone, pull and viewing diffs. Commit, push, branching and merge conflict resolution from inside the app need a paid edition, but nothing stops you from using plain git in a terminal.

The Bruno CLI (npm install -g @usebruno/cli, command bru) runs a collection, a folder or a single request against a named environment. Docker images and a GitHub Actions integration are documented, with JSON, JUnit and HTML reports.

Where it is strong.

• A request change is a file diff. Reviewers see exactly which header, body or test changed, in the same pull request as the code change that needed it.
• Secret variables are a separate tab in an environment. The environment file keeps only the variable name. The value stays in Bruno’s local encrypted store, using OS-level encryption when available, and is not exported.
• A .env file at the collection root can hold secrets, read through process.env, with the usual rule of adding it to .gitignore.
• No account or licence key is needed for the open-source app.

What to watch.

• There is no shared server. Collaboration means Git, with its branches, pulls and conflicts.
• Secret manager integration (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager) is marked as a premium Ultimate feature in the docs.
• The docs say telemetry is enabled by default, with a toggle under Preferences, About. Turn it off if your policy needs that.
• Plan the .bru to YAML move. The migration removes the original .bru files, and scripts that call bru.runRequest() with a .bru path must be updated.

Hoppscotch (formerly Postwoman): a team workspace you can host yourself

History and licence. The project began as Postwoman. The old liyasthomas/postwoman GitHub URL now redirects to hoppscotch/hoppscotch, a repository created in August 2019. The licence file is MIT. Hoppscotch Limited runs the hosted Hoppscotch Cloud. The self-hosting docs describe two editions: Community Edition, free and MIT licensed, and Enterprise Edition, which the docs call open-core, with SAML SSO, OpenID Connect, audit logs, access controls and priority support. The cloud pricing page lists a Free plan and paid Business and Enterprise plans. The latest release is 2026.10.1, published on 5 November 2026 (1:45 PM IST).

How it works. Hoppscotch started as a web app and is still web-first, with an installable PWA, desktop apps for Windows, Linux and macOS, and a CLI. When you self-host, Hoppscotch runs as a set of Docker containers with a Postgres database that stores the data, and it needs an OAuth provider (email, GitHub, Google or Microsoft) for sign-in. Collections can be exported as files, and the importer accepts Postman, Insomnia and OpenAPI formats.

The Hoppscotch CLI (npm i -g @hoppscotch/cli, command hopp test) runs tests from an exported collection file, or from a collection on your cloud or self-hosted instance using a personal access token. The docs mark the CLI as alpha and say it now needs Node.js 22 or later.

Where it is strong.

• The closest of the three to the “shared workspace” feel that Postman users know, but the server and its database can sit inside your own network.
• Secret environment variables are never synced to the server or shared with workspace members, according to the docs. Each user fills in the value at run time, values are masked, and they are not exported or copied when you duplicate an environment.
• Very wide protocol support in one place: REST, GraphQL, WebSocket, Server-Sent Events, Socket.IO and MQTT.

What to watch.

• Regular (non-secret) environment variables in a shared workspace are synced to the server and visible to all members.
• Review in Hoppscotch is a workspace activity, not a pull request. Activity logs and audit logs are listed as Enterprise features.
• You now run one more service: Postgres, OAuth apps, SMTP for invites, upgrades and backups. The Community Edition docs say updates are your job.
• Self-hosted Community Edition sends a weekly anonymous instance ping (user and workspace counts, version). It can be turned off in the admin dashboard under data sharing.
• A browser tab cannot reach every private API on its own. Hoppscotch offers a proxy, an agent and the desktop app for that.

Insomnia: one desktop app, three storage choices

History and licence. Insomnia started as a side project by Gregory Schier, moved from a Chrome app to an open-source desktop app, and was acquired by Kong, which announced the deal on 2 October 2019. The old getinsomnia/insomnia URL now redirects to Kong/insomnia, and the licence is Apache-2.0. The latest stable release is 13.4.0 (tag core@13.4.0), published on 29 October 2026 (5:24 PM IST).

The account story is worth knowing because many teams still remember it. Insomnia 8.0 (released 28 September 2023, IST) required an account for most use and introduced the local Scratch Pad for account-free use. In Kong’s own GitHub discussion, the team said 8.x first supported local-only storage only through Scratch Pad (one collection) or Git Sync. Insomnia 8.3 (16 October 2023, IST) brought back fully local projects as Local Vault, and changed migration from older versions to default to Local Vault. What is true now, per the current README: Scratch Pad works without an account, most other capabilities need one (free is enough), and project data stays in the storage backend you choose.

How it works. Each project uses one of three storage backends: Local Vault (fully local), Git Sync (YAML files in your own Git repository, without going through Insomnia’s cloud) or Cloud Sync (optionally end-to-end encrypted). Git Sync acts as a Git client inside the app with branches, commits, push, pull, merge and a three-way merge view, and branch protections on your Git host still apply. The UI exports Insomnia YAML (v5) and HAR, and imports Postman, OpenAPI, HAR, WSDL and cURL among others.

The Inso CLI (inso) runs collections and test suites, lints OpenAPI specs and exports specs. It reads data from the .insomnia directory that Git Sync creates, or from the local app data, and a kong/inso Docker image is available.

Where it is strong.

• One tool for API design (OpenAPI editor and linting), debugging, test suites, collection runner and mocks.
• Private sub-environments are never synced or exported, and need a vault key to open. The README says Private Environments stay local whatever storage you choose for the project.
• You can pick storage per project. A sensitive banking project can sit in Local Vault or Git while a public demo project uses Cloud Sync.
• Git Sync on the free Essentials plan covers up to 3 users, per the pricing page.

What to watch.

• Account management is in Kong’s cloud even when your project data is local. If your policy forbids any vendor login on developer machines, only Scratch Pad remains.
• Usage analytics are collected if you are logged in or have not opted out in the app, according to Kong’s collected-data page. Read it and set your preference.
• Git Sync for more than 3 users, RBAC and unlimited organisations sit in the paid Pro plan. SSO, SCIM, storage mandates and native vault integrations (AWS, GCP, HashiCorp, Azure) are listed under Enterprise.
• Git Sync also writes app metadata into the repository, so expect some diffs that are not request changes.

Side by side

• Collections at rest. Bruno: plain files in your folder, always. Hoppscotch: rows in a server database, cloud or self-hosted, with file export. Insomnia: your choice per project, local app storage, YAML in Git, or cloud with optional end-to-end encryption.
• Secret values. All three now have a “do not sync, do not export” kind of variable: Bruno secret variables, Hoppscotch secret variables, Insomnia private sub-environments. External secret managers are a paid feature in Bruno (Ultimate) and Insomnia (Enterprise).
• Review path. Bruno and Insomnia Git Sync give you a pull request. Hoppscotch gives you a shared workspace, with audit logs in Enterprise.
• Account. Bruno: none. Hoppscotch: an account on your own instance or on Hoppscotch Cloud for shared work. Insomnia: Kong account for everything except Scratch Pad.
• CI runner. bru run, hopp test (alpha) and inso run collection.

How to choose

• If your rule is “API knowledge lives next to the code and every change is reviewed”, start with Bruno. It is the simplest model and needs no server.
• If your team wants a live shared workspace in the browser, and compliance says it must run on your own servers, start with self-hosted Hoppscotch Community Edition, then check whether you need Enterprise for audit logs.
• If you want design, mocks and tests in one desktop app, with Git storage for sensitive projects and cloud for the rest, start with Insomnia, after your security team accepts the account requirement.

For the Hyderabad team, the likely answer is Bruno or Insomnia Git Sync in the same repository as the payments service, with production credentials removed from every shared environment and fetched by each engineer from the company vault. That answers both audit questions: Git history shows what changed, and nobody’s collection holds the production token.

Common mistakes

• Moving the bad habit to a new tool. A migration copies the shared production token straight across. Clean up first.
• Committing secrets by accident. In Bruno, use the Secrets tab or a git-ignored .env. In Insomnia, use private sub-environments. In Hoppscotch, use secret variables, not regular ones.
• Assuming “open source” means every feature is free. All three have a paid line.
• Ignoring telemetry defaults. Bruno and Insomnia collect usage analytics unless you opt out, and Hoppscotch self-host sends a weekly instance ping. Decide your policy and document it.
• Never running the collection in CI. A collection that only runs on laptops goes stale. Use bru run, hopp test or inso run collection on every merge.

Start this week

1. List every shared environment and mark variables holding real secrets. Rotate widely shared production ones.
2. Pick one small service and one tool. Import the existing collection (all three importers accept Postman collections).
3. Move secrets into the tool’s secret mechanism, or reference them from your existing vault or a git-ignored .env.
4. For Bruno or Insomnia Git Sync, commit the collection next to the service code and require review for changes. For Hoppscotch, set up workspace roles and decide who can edit.
5. Add one CI job that runs the collection against a staging environment with a short-lived token.
6. Decide telemetry settings and write them into your team’s onboarding page.

A short checklist

• Collections stored where your data policy allows, with backups.
• No secret values in any committed, exported or synced file.
• Production credentials not available in shared environments at all.
• A clear review path for request changes: pull request or workspace roles.
• A CLI run in CI for at least one collection.
• Licence, account requirement and paid features read and accepted.
• Telemetry settings decided and documented.

No hands-on drill

No hands-on drill was run for this post, and nothing was installed or tested. The facts come from each project’s repository, licence file, releases and official documentation, read on 8 November 2026, with release dates converted to IST.

Closing

The revisit here is small but useful. Learn where your API client keeps collections and secrets, unlearn the habit of sharing an environment to fix a bug, re-learn how a request change gets reviewed, practise on one service, and apply the same pattern across the team. The rule matters more than the tool: the collection is shared, the production token is not.

Sources

• Bruno repository: https://github.com/usebruno/bruno
• Bruno licence file (MIT): https://github.com/usebruno/bruno/blob/main/license.md
• Bruno releases (v4.3.0, 22 October 2026): https://github.com/usebruno/bruno/releases
• Bruno pricing: https://www.usebruno.com/pricing
• Bruno licence overview: https://docs.usebruno.com/license-overview
• Bruno OpenCollection YAML format: https://docs.usebruno.com/opencollection-yaml/overview
• Bruno YAML migration: https://docs.usebruno.com/bru-lang/yaml-migration
• Bruno Git collaboration: https://docs.usebruno.com/git-integration/overview
• Bruno secret variables: https://docs.usebruno.com/secrets-management/secret-variables
• Bruno DotEnv file: https://docs.usebruno.com/secrets-management/dotenv-file
• Bruno secret manager integration: https://docs.usebruno.com/secrets-management/secret-managers/overview
• Bruno CLI: https://docs.usebruno.com/bru-cli/overview
• Bruno migrating from Postman: https://docs.usebruno.com/get-started/import-export-data/postman-migration
• Hoppscotch repository: https://github.com/hoppscotch/hoppscotch
• Hoppscotch licence file (MIT): https://github.com/hoppscotch/hoppscotch/blob/main/LICENSE
• Hoppscotch releases (2026.10.1, 5 November 2026): https://github.com/hoppscotch/hoppscotch/releases
• Former Postwoman repository URL (redirects to Hoppscotch): https://github.com/liyasthomas/postwoman
• Hoppscotch self-host editions: https://docs.hoppscotch.io/documentation/self-host/getting-started
• Hoppscotch Community Edition prerequisites: https://docs.hoppscotch.io/documentation/self-host/community-edition/prerequisites
• Hoppscotch Community Edition telemetry: https://docs.hoppscotch.io/documentation/self-host/community-edition/telemetry
• Hoppscotch environments and secret variables: https://docs.hoppscotch.io/documentation/features/environments
• Hoppscotch CLI: https://docs.hoppscotch.io/documentation/clients/cli/overview
• Hoppscotch pricing: https://hoppscotch.com/pricing
• Insomnia repository: https://github.com/Kong/insomnia
• Insomnia licence file (Apache-2.0): https://github.com/Kong/insomnia/blob/develop/LICENSE
• Insomnia releases (13.4.0, 29 October 2026): https://github.com/Kong/insomnia/releases
• Kong acquires Insomnia (2 October 2019): https://konghq.com/blog/news/kong-acquires-insomnia
• Insomnia 8.0 release post: https://konghq.com/blog/product-releases/insomnia-8-0
• Insomnia 8.3 brings back local projects: https://konghq.com/blog/product-releases/insomnia-8-3
• Insomnia 8.x account and storage discussion: https://github.com/Kong/insomnia/discussions/6590
• Insomnia Local Vault discussion: https://github.com/Kong/insomnia/discussions/6626
• Insomnia Git Sync: https://developer.konghq.com/insomnia/git-sync/
• Insomnia environments: https://developer.konghq.com/insomnia/environments/
• Insomnia collected data: https://developer.konghq.com/insomnia/collected-data/
• Insomnia import and export: https://developer.konghq.com/insomnia/import-export/
• Inso CLI: https://developer.konghq.com/inso-cli/
• Insomnia pricing: https://insomnia.rest/pricing