Free desktop app
Studio
A desktop API client for macOS, Windows and Linux, built around your OpenAPI spec (Swagger 2.0 opens too). Requests are built from the spec, responses are checked against it, and schemas are easy to browse. Free, open source, and it works with no account.
macOS, Windows and Linux · free and MIT licensed · no account needed
The idea
Stop describing your API twice.
Most API clients ask you to rebuild, by hand, something you already have. You own a spec that says what the endpoints are, what the parameters mean, and what a valid response looks like — and then you maintain a collection that says the same thing, less precisely, and drifts the moment the API changes.
Studio starts from the spec instead. Requests are generated from it, responses are checked against it, and when the contract changes the client changes with it. There's nothing to re-record.
Body — generated from the schema
{
"customerId": "cus_4Qk28Rd",
"currency": "EUR",
"items": [{ "sku": "SKU-1042", "qty": 2 }]
} See it work
Open a spec, send a request, look at it in History.
What's in it
A real client, not a spec viewer.
Requests built from the spec
Forms follow what the spec says. A list of allowed values becomes a dropdown, a true/false becomes a toggle, and bodies start filled in with the real field names. A server written as a path, like /api/v3, works against the spec's own address.
no collection to maintain Swagger 2.0 opens too
OpenAPI 3.0 and 3.1 open as they are. A Swagger 2.0 spec is converted to OpenAPI 3.0 when you open it, on your computer. The Raw tab still shows the original file, and Studio says where the conversion may not be exact.
no separate converter needed Schemas and the graph have their own tabs
Schemas (the data models) sit next to operations, not inside them. See each one's fields, what it uses and what uses it, and an example. The Graph tab shows how the schemas refer to each other.
Operations · Schemas · Graph · Document Responses checked against the spec
Each JSON response is checked against the schema the spec declares for the status code that came back. That includes fields the spec never mentions, which is often the first sign of drift. Headers aren't checked yet.
including undeclared fields Collections that chain across APIs
Run steps in order, such as create an order, get it, then pay for it, across several specs. Each step points at an operation in its spec and is checked against it. Pass a value from one step's response to a later step, and see every link in the Chain view.
broken links shown, with a fix Failure cases, spec changes, and git
A step can expect a 404 or any 4XX, to test a failure case. When a spec changes, a step that no longer matches it says what changed. Save a collection as a YAML file and keep it in git next to your specs.
no secrets in saved files Run logs and a console
Each collection run keeps a log: every step's request, response, the values it took from earlier steps, and why it failed. The console (⇧⌘Y) shows this session's requests, runs, local mock traffic and MCP calls.
kept on your computer Local mocks in one click
Start a mock of any spec in your library on this computer, with no account and no network. Ask for a status or a named example with a header, and a frontend on localhost can call it from the browser.
127.0.0.1 only · stops when Studio quits Import from Postman
Bring in a Postman collection (v2.1 or v2.0). Each request is linked to an operation in your specs where it matches, status tests become expected statuses, and saved response values become links. Tokens and passwords never land in the collection.
scripts are never run Request tabs that keep your work
Every request you open gets a tab, across APIs. What you type stays with it when you move away, and after a restart, and the last response comes back with the request.
back after a restart Conformance runs
Run every operation in a tag, or the whole spec, and see which responses match. The checks come from the spec, so there are no test scripts to write. Export the result as Markdown.
read-only requests by default History is a read-only log
Each request is saved with what was sent, what came back, and the check result from when it ran. Re-check it against the current spec, filter one list across all your APIs, or copy it to a new request.
kept 30 days, on your computer Environments and OAuth 2.0
Keep values like {{baseUrl}} and {{token}} in named environments. Mark a value secret and it goes to your operating system's credential store. Studio can get OAuth 2.0 tokens for you.
secrets stay out of your files No CORS problems, and works on company networks
The app sends requests itself, not through a web page, so browser CORS rules don't apply. Trust a private certificate authority for specific hosts, and set a proxy, timeouts and redirects.
no proxy needed for localhost Hosted mocks in one dialog
Choose Create mock on an API you opened from a file or a URL. Studio walks you through signing in, choosing a team, publishing the API inside your organisation and creating the mock, and skips steps you have already done. It keeps the mock's address and key for you.
needs a Spec0 account A local MCP server
Let a coding agent on your computer see the APIs open in Studio: list them, read specs and operations, and search. It is off until you start it, listens only on this computer, and needs a token.
never shares secret values Open in Studio links
The Open in Studio button on Spec0's public API pages opens that API here. Studio asks before it downloads anything, shows where the spec comes from, and only accepts https addresses.
nothing is fetched until you confirm Settings in one place
One Settings page (⌘, or Ctrl+,) for your Spec0 account, network settings, updates, appearance, the MCP server, and data and privacy. Check for Updates… installs a newer version, and every update is signed.
you decide when it checks Privacy
A client for internal APIs has no business talking to anyone else.
Studio makes no request you didn't ask for. No telemetry, no analytics, no crash reporting.
-
The rendered reference never fetches
The renderer is handed the document text, never a URL. A spec whose description references a remote image will not load it — that request would tell whoever wrote the spec that you opened it.
-
A content security policy enforces it
Not a promise about today's dependencies — a policy on the webview that holds regardless of what any bundled library decides to do in a future version.
-
Secrets go to your credential store
Secret values are kept in the macOS Keychain, Windows Credential Manager, or the Linux Secret Service, not in the environment file, so that file is safe to commit. If the store can't be reached (mostly on Linux without an unlocked keyring), Studio uses a plain local file instead and tells you so.
-
Secret values stay out of history
History, error messages, collection files and exported reports show
{{name}}in place of a secret value. Auth values are never stored per API, so there is one place for secrets, not two. -
Certificate trust is deliberate
Per-host, and there is no global "ignore TLS errors" switch — that's how a tool teaches people to stop reading warnings. Skipping verification for a host is shown at send time.
-
The MCP server stays on your computer
It is off until you start it, listens only on this computer, and turns away any request without its token. It never hands secret values to an agent.
-
Local mocks answer only this computer
A local mock listens on 127.0.0.1 only, and only while you have it running. Web pages can call it only when they are served from localhost, so a site you visit can't read your specs through it.
-
Logs stay local
Collection run logs are kept next to your other Studio data, and the console lives in memory for the session. Secret values are replaced by their names in both, and neither is sent anywhere.
-
Links ask before they fetch
Any web page can send an "Open in Studio" link, so Studio shows where the spec would come from and downloads nothing until you press Open. It only accepts https addresses.
-
Update checks only when you ask
Check for Updates… sends one request to github.com for the latest release, and nothing about your specs, environments or history. Checking each time Studio starts is a setting, and it is off unless you turn it on.
Free, open source, and it works with no account.
Opening a spec, browsing operations and schemas, sending requests, checking responses, collections, local mocks, environments and history all work with no sign-in. Connecting a spec0 organisation adds your team's APIs and hosted mocks. Signing out takes you back to local-only use, and nothing is lost.
-
macOS
Downloadspec0-studio-macos-universal.dmgmacOS 11 or later. Apple silicon and Intel. Signed and notarized by Apple.
-
Windows
Downloadspec0-studio-windows-x64-setup.exeWindows 10 and 11, x64. Installs for your user, no admin rights needed. Not code-signed yet (see below).
-
Linux (AppImage)
Downloadspec0-studio-linux-x86_64.AppImagex86_64, most distributions. Make it executable with chmod +x, then run it.
-
Debian and Ubuntu
Downloadspec0-studio-linux-amd64.debx86_64. Install with sudo apt install ./spec0-studio-linux-amd64.deb
The Windows installer is not code-signed.
We don't have a Windows code-signing certificate yet, so Windows SmartScreen will probably
say "Windows protected your PC". To continue, click
More info, then
Run anyway. If you'd rather check
the file first, compare it with SHA256SUMS.txt on the
release page.
Linux needs WebKitGTK 4.1, which means Ubuntu 22.04, Debian 12 or newer, or a distribution of about that age. The Windows and Linux builds are x86_64 only. They are newer than the Mac build, so please tell us if something looks wrong.
The platform
Part of the spec0 platform
MCP Layer
Live API context for every coding agent.
API Registry
One governed home for every internal API.
Mock Servers
A schema-accurate mock the moment you publish.
Governance & Quality
Catch breaking changes before they ship.
AI Workflows
Spec-aware automation across your APIs.