Branches as variants
main is prod. staging is what's about to ship. Feature branches scope new endpoint design. Switch in the editor; the spec updates.
Link any GitHub repo. Edit visually. Commit, branch, and tag right from the editor — with structural diffs, PR review, and auto-changelogs. Even your non-GitHub teammates ship through the same workflow.
Most teams version their API spec like it's a Google Doc. Your code wouldn't tolerate that — your spec shouldn't either.
Your spec history lives in Postman or Stoplight, not next to the code that consumes it. Switch tools and the trail vanishes.
Designing v2 while v1 still ships? In most editors that's a copy-pasted "draft" with no merge story.
Without git, "approve the breaking change" becomes a Slack thread. With git, it's a PR with line-by-line review.
Install the OpenAPI Studio GitHub App on the repo you want — or just paste a public repo URL. Pick the file (openapi.yaml, spec.json, anywhere in the tree) and the branch.
Edit in the flow builder, table view, or raw editor — your changes stay local until you hit Commit. Modal asks for a message, picks the branch, detects conflicts before you push.
Switch branches with one click. Publish v1.2.0 as a real git tag. Open a PR straight to GitHub for review — no in-app review reinvention.
main is prod. staging is what's about to ship. Feature branches scope new endpoint design. Switch in the editor; the spec updates.
"Publish v1.2.0" creates a real git tag. Public hotlinks resolve ?version=v1.2.0 to the tagged ref — frozen, cacheable, immutable.
Compare any two commits and see "added GET /users · removed required field email · response 200 → 201" — not 47 lines of indentation drift.
Conventional Commits on the spec file (feat:, fix:, breaking:) generate a CHANGELOG.md next to the spec — no extra tooling.
Editor without write to main? Commits land on a feature branch and auto-open a PR. Review in GitHub, merge to ship — same flow your team already runs for code.
Public-repo specs stream from raw.githubusercontent.com with edge caching. Webhooks invalidate on push. No D1 read on the hot path — costs nothing at scale.
| Capability | OpenAPI Studio + GitHub Sync | Postman | Stoplight | Hand-rolled YAML in repo |
|---|---|---|---|---|
| Real git history | Yes | Cloud-only | Paid tiers | Yes |
| Visual flow editor | Yes | No | Yes | No |
| Branch from UI | Yes | No | Paid | Manual git |
| Tags as API versions | Yes | No | Limited | Manual |
| Non-GitHub teammates can commit | Yes (App) | N/A | Per-seat | No |
| Structural OpenAPI diff | Yes | No | Yes | No |
| Free tier covers it | Yes | Limited | No | Yes |
Postman locks history in their cloud and has no visual flow editor. We give you both, on a real git remote you already trust.
Stoplight does git sync — behind paid tiers. We do it on free, with a flat-priced Pro that doesn't scale per seat.
Editing YAML by hand gives you git but no visual editor, no validation, no execution, no MCP. Add those and you've rebuilt half of OpenAPI Studio.
We use a GitHub App installed on the repo, not per-user OAuth. The install is workspace-bound, so a Google-signed-in editor or an email-invited collaborator can commit through the same workflow as your GitHub-native devs. Commits are authored by the human who hit save and committed by the App — accurate attribution, no shared bot accounts, no per-seat git licenses.
Free covers a single workspace. Pro is $9/mo flat — never per-seat.