Auto-Generate Bruno Collections From Your OpenAPI Specs
Teams ship OpenAPI specs.
Developers need usable API collections.
Those two things are almost never kept in sync.
Every time a developer starts integrating with your API, they end up:
- Importing a Postman file that's already stale
- Fixing broken request bodies
- Guessing auth flows
- Digging through GitHub issues for accurate examples
This is unnecessary friction. And it wastes time at scale.
So I built OpenAPI Catalog, a fully automated pipeline that turns
OpenAPI specs into Bruno collections + clean HTML docs, always
synced to the source of truth.
👉 https://openapicatalog.com/\
👉 Open source repo: https://github.com/rreyn-bruno/openapi-catalog
Why Collections Should Come From the Spec, Not Maintained By Hand
1. Specs are the truth. Collections are the interface.
The spec declares what your API is.
The collection shows developers how to use it.
Today, most companies maintain both manually. That guarantees drift.
When the collection is generated from the spec:
- No rot
- No missing endpoints
- No human error
- No out-of-sync environments
This eliminates a huge source of DX pain.
2. Bruno collections are Git-native, local-first, and deterministic
This is the real unlock.
Bruno isn't cloud-locked or bloated. It stores everything in plain
files, diffs cleanly, and works offline. That means an autogenerated
collection becomes a first-class artifact in your repo, just like:
-
openapi.yaml - SDK code
- Migration files
- Scripts
You get:
- Clear diffs when your API changes
- Collections versioned per release tag
- CI-driven generation
- A reproducible workflow instead of a manual export
This is structurally better than maintaining a Postman export in your
repo.
3. Documentation improves automatically
OpenAPI Catalog generates clean, fast HTML docs for every spec it
processes.
Developers get:
- A readable reference
- No massive Swagger UI bundles
- No Try-It sandbox issues
- No need for a separate docs pipeline
Docs and collections now stay perfectly aligned with the spec.
How OpenAPI Catalog Works (Technical Overview)
- Discover OpenAPI files across GitHub and other sources
- Parse, lint, and validate the spec
- Generate a Bruno Collection mirroring the API structure
- Produce HTML documentation automatically
- Host everything with download links
- Rebuild on spec changes from upstream
The system is built to be:
- Automated
- Deterministic
- Scalable
- Easy to fork or extend
The entire pipeline is open source:
https://github.com/rreyn-bruno/openapi-catalog
Why API Publishers Should Ship Bruno Collections
Better onboarding
Developers start with working request examples, no editing raw JSON, no fixing broken imports.
Better engineering workflow
API changes become obvious through diffs in both the spec and the
collection.
Better versioning
Collections track release tags, branches, and environments cleanly.
Better ecosystem integration
Bruno collections are portable, local, and friendly to CI systems.
For forward-thinking teams, this becomes part of the release pipeline:
# CI pseudocode
generate-bruno-collection openapi.yaml > collection/
publish collection/ alongside openapi.yaml
Or skip the pipeline entirely and let the catalog do it:
Call for Contributors & API Maintainers
The project is open source and early. Contributions are welcome,
especially around:
- New spec sources
- Better generators
- Improved docs
- CI integration examples
- API maintainers who want their API indexed
If you maintain an API and want a synced Bruno collection + docs
generated automatically, open an issue or drop your repo.
OpenAPI is the source of truth.
Bruno is the developer interface.
This project connects the two... automatically.
Top comments (0)