OpenAPI Studio
GitHub · 2026

Your code lives in git. Your spec should too.

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.

  • Two-way sync, conflict-aware
  • Tags become API versions
  • Public repos = free hotlinks
openapi.yaml 3 branches · synced main feat/user-roles · merged feat/billing · ahead by 2 v1.0.0 initial release v1.5.0 + user roles v2.0.0 latest · public YOUR API SPEC · WITH A REAL GIT HISTORY
The status quo

Specs deserve real history, not a version dropdown in someone's cloud.

Most teams version their API spec like it's a Google Doc. Your code wouldn't tolerate that — your spec shouldn't either.

01

Locked in a vendor's cloud

Your spec history lives in Postman or Stoplight, not next to the code that consumes it. Switch tools and the trail vanishes.

02

No real branching

Designing v2 while v1 still ships? In most editors that's a copy-pasted "draft" with no merge story.

03

Reviews live in screenshots

Without git, "approve the breaking change" becomes a Slack thread. With git, it's a PR with line-by-line review.

How it works · three steps

From spec to committed change in under a minute.

  1. 01

    Link your repo

    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.

  2. 02

    Edit visually, commit explicitly

    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.

  3. 03

    Branch, tag, open a PR

    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.

What you get

A versioning model that looks like git, because it is git.

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.

Tags as API versions

"Publish v1.2.0" creates a real git tag. Public hotlinks resolve ?version=v1.2.0 to the tagged ref — frozen, cacheable, immutable.

Structural diffs, not YAML noise

Compare any two commits and see "added GET /users · removed required field email · response 200 → 201" — not 47 lines of indentation drift.

Auto-changelog

Conventional Commits on the spec file (feat:, fix:, breaking:) generate a CHANGELOG.md next to the spec — no extra tooling.

PRs for design review

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 repos = free hotlinks

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.

vs the rest

Other editors do some of this. None do all of it on a free tier.

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
  • vs Postman

    Postman locks history in their cloud and has no visual flow editor. We give you both, on a real git remote you already trust.

  • vs Stoplight

    Stoplight does git sync — behind paid tiers. We do it on free, with a flat-priced Pro that doesn't scale per seat.

  • vs hand-rolled YAML

    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.

Auth · GitHub App, not OAuth-per-user

Your whole team ships — even the ones without GitHub.

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.

  • GitHub-linked editor Commit shows their avatar & profile on github.com
  • Google sign-in editor Commit shows their name & email — no GitHub seat needed
  • Email-invited reviewer Read-only by default; can be promoted to commit without a GitHub account

Five minutes from now, your spec lives in your repo.

Free covers a single workspace. Pro is $9/mo flat — never per-seat.