Bruno API Client | Blog & News

Operational Chaos: API Tools Outside of Git

Written by Ryan Reynolds | Aug 15, 2025

Since inception, most API clients have followed the same pattern: create a proprietary cloud platform where formats, workflows, and data are locked in, then charge extra to secure them.

For more than a decade, Git has been the universal language of software development. It is how modern companies build, deploy, and manage the APIs that power their products.

So what makes API collections so special that they must live outside of Git and the rest of the SDLC? More importantly, what is the justification for running two of everything: two histories, two permission models, two audit logs, two places to secure secrets?

Every duplicated system is another set of processes to maintain, permissions to audit, and points of failure to investigate. That duplication wastes time, fragments workflows, and increases risk.

This makes absolutely no sense to us, and is why we are committed to flipping this paradigm.

Bruno keeps collections as files in your repo, versioned in Git, right next to the code they belong to. No extra layer to manage. No parallel workflows to reconcile. We are not trying to be your platform. We are the connective layer between the platforms you already use and trust.

Centralization is the right goal. The center of modern software development is Git. Everything else should align to it, not compete with it.

1) Git is already your source of truth

  • Git is the global standard for version control in software development. It is how products are built, reviewed, and deployed.
  • Putting API tests and documentation anywhere else creates a second source of truth. That is where silos and drift start.
  • Internal Developer Portals like Backstage and Port sit on top of Git. They present the information and add helpful services, but they still point back to the repo.
  • An API client will never be the origin document. Collections are not the source. The broader codebase is.

A house needs its foundation before the electrical system. You can design the smartest wiring in the world, but it will never replace the concrete that holds the structure together. In the same way, no UX or integration will turn an API client into the foundation of your workflow. Git is the foundation.

2) Productivity starts with findability

  • New developers waste time hunting for the right collection, test suite, or example request.
  • Every extra step to check another tool adds friction. Friction compounds across a team.
  • Keeping collections next to the API code means a single git clone provides the service, the tests, and the docs.

Decentralizing this into a separate platform is not just inconvenient, it is counterproductive.

3) Security is strongest where you have already invested

  • Companies spend heavily in money, time and resources to secure dev environments and Git providers with roles, permissions, audit logs, and enforcement.
  • GitHub and similar providers offer mature controls, including secret scanning that catches credentials before they spread.
  • Adding a new storage location expands your attack surface and doubles policy and monitoring work for security teams.
  • Creating another place for secrets often becomes a business model. First create the gap, then sell you the fix.

Keep the fortress intact. By storing collections in Git, the permissions and security controls you have already configured and invested in cascade automatically. No new gates to guard.

4) Versioning and collaboration are built in

  • Pull requests, code review, CI hooks, and automated testing come standard with Git.
  • Diffing, branching, and conflict resolution are solved problems. No reinvention required.
  • Every change to a collection lives beside the code it exercises. No mystery diff between what you tested and what you shipped.

Adding another version control layer on top of Git is not just unnecessary, it is counterproductive and a bit of hubris. Git already won. Duplicating its job only adds friction, fragments history, and creates more places for things to go wrong.

The bottom line

API collections are part of your development workflow. Keeping them in Git is simpler, safer, and faster. Bruno is built around that reality. We are not here to replace Git or to become your central platform. We connect the tools you already trust without adding friction or new security gaps you have to pay to close.

Practical tip for teams: keep your collections in the same repo as the service whenever possible, or in a mono-repo with clear structure and code owners. Pair PRs that change endpoints with updates to the collections so reviews stay in one place.