Say you own a collection of API requests that your team uses every day. A new developer asks how to get started, and you want an answer better than a zip file and a wiki page. You have also been told your API needs to be readable by machines, not just people. Those two jobs feel like the same job. A post on the APIs.io blog about Bruno suggests they are not.
Bruno has published a guide to sharing collections and API docs publicly, and its opening line carries the whole argument: "Your collection is already the most accurate description of your API." From there it offers you two routes.
The first is to push your collection to a public Git repository and put a Fetch in Bruno button in the README. A reader clicks once and gets a real Git clone, not a snapshot, and it pulls your updates whenever you push. The second is to open the collection's Overview tab, click Generate Docs, or run bru docs generate in CI. You get a single HTML file with a Try playground and code samples, and you can host it anywhere static files live. Bruno's recommendation is to do both from one Git-backed collection, and it says everything in the post works in the free edition.
The post finds very little marketing to discount, and the free-versus-paid line is drawn honestly. Initializing Git, the button, the reader's clone, fetch and pull, and doc generation are free. Connecting a remote, committing, pushing and branching from inside the app's Git UI need Pro, Ultimate or a trial. So if you were planning to do all your publishing from within the app, you would hit that wall.
The security advice is concrete too, and you would want to read it before publishing anything. Secret environment variables are masked and kept off disk. External secrets are fetched from a provider at run time. Neither lands in the repository or in the generated HTML.
Here is the detail that matters most if you already maintain a spec. The same button accepts an OpenAPI 2.0 or 3.x URL with type=openapi and converts it into a collection on the reader's machine. Your existing contract does not have to be thrown away. It becomes the starting point for what the reader clones.
The catalog record agrees with this architecture. Bruno on apis.io is described as a git-native, offline-first developer tool rather than a hosted API. The pieces the guide walks through each have a page: the Bruno API Client that renders the button's clone, Bruno Git Integration and Sync that carries every update, the Bruno CLI (bru) that generates the docs in CI, and the OpenCollection Format and Bru Markup Language (.bru) the collection is actually written in.
Then the post turns the measurement on Bruno itself. Bruno scores 50.4 on the Kin Score, which is developing, carried by access clarity at 92.1 and discoverability at 71.7. Contract quality is 0.0 and contract governance is 18.2. Agent Readiness sits at 9.6 with spec presence unlit.
The post calls that mostly fair, because the catalog record says Bruno does not expose a documented public REST API. There is no contract of Bruno's own to score. But the post also points out that this is the very gap it describes for everyone else. A collection is a description of an API that a person can click, while a machine still needs a spec. Bruno's own button already knows this, which is why it takes an OpenAPI URL.
So you go back to your own situation with a clearer view. Your collection can be the best onboarding experience your team has ever offered, with a one-click clone and a hosted docs page that updates from CI. That is a real win, and Bruno's guide shows how to get it without paying. But it does not replace the contract. If you want a machine to understand your API, the spec still has to exist and be published, and the button is only as useful to machines as the OpenAPI file behind it.
What you take away is simple. Publish the collection for the people who will click, keep the spec for the readers that cannot, and check which of Bruno's Git features need a paid tier before you plan your workflow around them.
Read the original: https://apis.io/2026/11/03/bruno-fetch-button-publishes-the-collection-but-not-a-contract/