What's new in Spec0.

Until now every listing on the public registry was put there by us. You could publish one with spec0 publish from a terminal, but there was no way to do it from the product — and the “import from GitHub” flow, which looked like the answer, only ever created an API that stayed inside your organisation.

Now it does both. Point Spec0 at the repository your spec already lives in, choose public, and it becomes a listing anyone can read.

• Nothing to add to your repo. No workflow file, no secrets, no CI step. Spec0 reads the spec from the branch you nominate.
• Pull requests get checked. Every PR that touches the spec gets lint and breaking-change results posted back as GitHub checks — the same ones your private APIs get.
• You see the address before you commit to it. The confirmation shows the exact /registry/your-org/your-api URL, the branch being tracked, and what “public” means in plain words, before anything is created.
• Free for your first three.

Publishing a new version is still a step you take. Spec0 checks your pull requests automatically, but it does not publish when you merge — you publish again from the dashboard, or from your own CI with the CLI. We would rather say so here than have you find out from a listing that quietly went stale.

The registry is easier to browse

The front page opened with a headline and a paragraph, so the list of APIs — the reason anyone visits — started below the fold. It now opens on the APIs themselves.

• Companies have their logos, not coloured initials.
• A flat list by default, each row naming its owner, with a Companies view for browsing by vendor instead.
• The rest of Spec0 is one click away — docs, the CLI, the mock server and Studio now sit in the registry’s own header.

And the two things people most want to do with a published spec have their own pages: connect an AI agent over MCP, with setup for Claude Code, Cursor, VS Code or any other client, and mock any API in it.

Spec0 Studio is our free, open source desktop app for calling and testing APIs from their OpenAPI spec. Version 0.3.0 is out. Get it on the Studio page, or choose Check for Updates… in Studio.

• Collections. A collection runs steps in order, such as create an order, get it, then pay for it, across one or more APIs. Each step points at an operation in its spec, so every response is checked against that spec. Each step can go to its own target: a real server, a hosted mock, or a local mock. See Collections.
• Passing values between steps. Take the id that step 1 returned and use it in step 3, by clicking a value in a response or picking it from a list. The Chain view shows every link as a line from one step to the next, and after a run, the value each link passed. A link that can’t work, because its step was removed or now runs too late, is shown in red with a one-click fix.
• Testing failure cases. A step can expect a 404 or any 4XX, and passes when that status comes back and matches what the spec declares for it.
• Run logs. Every run keeps a log of each step: what was sent, what came back, the values it took from earlier steps, and why a step failed or was skipped. Copy it, or export it as JSON or text.
• Collections in git. Save a collection as a YAML file next to your specs. Studio re-reads it when it changes, for example after a git pull, and asks before overwriting anyone’s edits. Secret values are never written to it.
• Import from Postman. Bring in a Postman collection. Each request is linked to an operation in your specs where it matches, status tests become expected statuses, and values saved by scripts become links between steps. Tokens and passwords are never copied into the collection. Studio doesn’t run the scripts themselves.
• Local mock servers. Start a mock of any API in your library on your computer, in one click, with no account and no network. Ask for a different status or a named example with a header, and call it from a frontend on localhost. See Local mock servers.
• Request tabs. Every request you open gets a tab, across APIs. What you type stays with a request when you move away, and after a restart, and a dot shows which requests have unsent changes.
• A console. Press ⇧⌘Y (Ctrl+Shift+Y) to see this session’s requests, collection runs, local mock traffic and MCP calls in one place. It’s kept in memory only.
• A simpler Add an API dialog. It opens on your organisation’s APIs when you’re signed in, and on local files when you’re not.

The Studio docs have also been reorganised, with pages for each of these and a troubleshooting page.

Good to know:

• Collections run in Studio only. There’s no command-line runner yet.
• Local mocks answer from examples, not state. A POST doesn’t change what the next GET returns.
• The Windows installer is still not code-signed. Windows SmartScreen will probably warn you. Click More info, then Run anyway, or check the file against SHA256SUMS.txt on the release page first.

Please tell us what breaks, in issues or discussions.

Your agent already reads your own APIs through Spec0’s MCP server. Now it can read the public registry the same way, so “what fields does a Stripe charge have” is a question it can answer from the actual specification rather than from whatever it remembers.

Point it at a listing the way the URL does — stripe/api — and four things work:

• List the registry. Every published API, with its description and the reference to ask about next.
• Read the specification. Large ones come back as a structured overview rather than half a megabyte of YAML, so your agent orients itself without burning its context on a document it only needed the shape of.
• Read the changelog. The latest version, or a specific one by tag.
• Ask about a data shape by name. Not just the fields — also which operations carry that shape and which other schemas reference it. That comes from parsing every listing when it is published, so the answer arrives already assembled.

You need an account, and it is free. We went back and forth on this. Reading the registry in a browser needs nothing and never will. But a programmatic surface with no account behind it is one we cannot rate-limit per caller — only per IP, which any fleet of agents defeats simply by existing. Signing in is a small ask for something you are wiring into your editor, and it is what lets us keep the limits sane for everyone.

Two things deliberately left out. Operation search stays on your own APIs, because every call runs a vector search we pay for, and we would rather keep the public surface free than meter it. And a listing answers about its current version — schemas refresh whenever a vendor publishes a new one.

Spec0 Studio is our free, open source desktop app for calling and testing APIs from their OpenAPI spec. Version 0.2.0 is out. It is mostly about finding your way around, and about a few things that used to need another tool. Get it on the Studio page.

• Clearer navigation. Text tabs replace the icon toolbar: APIs, History, Mocks and MCP across the top, and Operations, Schemas, Graph and Document for the API you have open. The schema graph is now a tab of its own. The API’s name has its own row, so it is no longer cut short.
• A Settings page (⌘, or Ctrl+,) for your Spec0 account, network settings, updates, appearance, the MCP server, and data and privacy.
• Hosted mock servers in one guided dialog. Choose Create mock on any 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. It skips any step you have already done. It keeps the mock’s address and key, points your requests at it, and can send a first test request for you. See Hosted mock servers.
• A local MCP server, so a coding agent on your computer can see the APIs open in Studio: list them, read specs and operations, search, and, when you are signed in, get a mock’s address and key. It is off until you start it, listens only on this computer, needs a token, and never shares secret values. See Local MCP server.
• Swagger 2.0 specs open. Studio converts them to OpenAPI 3.0 when you open them, shows the original in the Raw tab, and says where the conversion may not be exact.
• “Open in Studio” links. The button on Spec0’s public API pages can now open an API straight in Studio. Studio always asks before downloading anything, shows where the spec comes from, and only accepts https addresses.

Fixes:

• Switching operations clears the response pane, so an old response is never shown next to a different request.
• A request still running when you switch away now goes to History only, instead of appearing next to another request.
• Signing in from Studio no longer signs you out of the spec0 CLI. Pressing Cancel on the sign-in page stops Studio waiting straight away.

Good to know:

• If you are on 0.1.1 or earlier, download this version by hand once. From 0.1.2 onwards, Check for Updates… installs it for you.
• Hosted mocks need a Spec0 account. Everything else works without one.
• The Windows installer is still not code-signed. Windows SmartScreen will probably warn you. Click More info, then Run anyway, or check the file against SHA256SUMS.txt on the release page first.

Thanks to everyone who tried 0.1.x and told us what broke. Please keep doing that, in issues or discussions.

Reading a contract and trying it are the same question

Every public API page now has a request client, and it is on for everyone — no account. Point it at your own server, or at the vendor’s, and send a real request while you are reading the reference.

What needs an account is our infrastructure, not the act of sending a request. If you are signed in and already have a mock of that API, it is offered as a target first, because it is the one that needs nothing configured.

You can also open any listing straight into Spec0 Studio from its page, with the spec already loaded.

Signing up after your colleagues

This one was a dead end, and it is worth describing plainly because we shipped it that way.

If someone from your company was already on Spec0 and you typed your company’s name when signing up, you got a conflict error. Trying again did the same thing, for ever. There was no way to ask to join them, and nothing told you they were there — so the second person from a company either gave up or quietly started a second organisation.

Now it offers. If your work email matches people already here, signing up shows you their organisation and lets you ask to join. An admin there accepts, and nothing happens until they do — you are never added to anything by a form. Your own workspace stays your own, and if nobody answers you can still set up your own organisation and carry on.

If you sign up with a personal address nothing changes: consumer email says nothing about where you work, so we do not guess.

Also in this release

• A confirmation email that never arrived no longer strands you. Subscribing to an API’s changes sends one confirmation. If it went to spam or never left, subscribing again used to do nothing at all, silently, for ever. It now sends a fresh one.
• API reference pages render the same way everywhere — the docs site, the app and the registry now share one renderer, themed to match.
• Signing in from the CLI and Studio is steadier, including a way forward when your account has no organisation yet.

Spec0 Studio is our free, open source desktop app for calling and testing APIs from their OpenAPI spec. Version 0.1.2 is out.

Windows and Linux. Studio now runs on Windows 10 and 11 (x64) and on Linux (x86_64), as well as macOS. Pick your platform on the Studio page.

• The Windows installer is not code-signed yet. We don’t have a certificate for that. Windows SmartScreen will probably warn you. Click More info, then Run anyway, or check the file against SHA256SUMS.txt on the release page first.
• Linux comes as an AppImage and a .deb. Both need WebKitGTK 4.1, so Ubuntu 22.04, Debian 12 or newer.
• These builds are new and have had much less use than the Mac build. If something looks or works wrong, please open an issue.

Also in this release:

• Check for Updates… is in the app menu on macOS and the Help menu on Windows and Linux. Studio only checks when you ask. There is a setting to check on start, and it is off by default. Updates are signed, and Studio won’t install one whose signature doesn’t match.
• Secret values live in your operating system’s credential store: the macOS Keychain, Windows Credential Manager, or the Secret Service on Linux. If the store can’t be reached, Studio uses a plain local file and says so. History, error messages and exported reports now show {{name}} instead of the secret value.
• History is a read-only log. Open an entry to see exactly what was sent, what came back, and the check result from when it ran. You can re-check it against the current spec. One list covers all your APIs, with filters. To run a request again, copy it to a new request.
• Relative server URLs work. If a spec opened from a URL lists its server as a path, like /api/v3, Studio resolves it against the spec’s address. The Swagger Petstore spec now works without typing a base URL.

Existing secrets move from the old file into the credential store the first time 0.1.2 starts. Nothing else needs doing.

Domains were meant to be the map of your API estate: Payments over here, Orders over there. In practice nobody ever finished making one, and it took us a while to work out why.

Membership was indirect. You tagged a schema payments, then created a domain that grouped the tag payments, and the domain contained everything carrying it. That works right up until you do it in the obvious order — create the domain first, then go looking for the button that puts a schema in it. There wasn’t one. Tagging a schema afterwards added it to nothing, because the domain’s tag list had already been fixed when you made it.

Now it is what it looks like. Create a domain, open a schema, pick the domain from a dropdown. A schema belongs to one domain, or none, and changing it is one click.

• Domains are a name and a description. No tag vocabulary to build first.
• The registry filters by domain — chips across the top of the schema list.
• The domain page lists its schemas, grouped by the API they come from.
• Agents can ask by name. list_schemas takes a domain like Payments rather than an identifier.
• The API graph draws the same relationship, so a domain’s node connects to the APIs that have something in it.

If you tried this before and gave up: your domains are still there. Open a schema and pick one, and it will populate immediately.

Teams live on one page

A team had a page showing everything about it and offering to change none of it — renaming meant leaving that page and finding the same team in a second list under Settings. That second list is gone. Rename, describe, delete and the service-account tokens link are all on the team’s own page now.

The dashboard navigates by subject

• APIs is a section, not just a link. Schemas, Domains and API graph sit beneath it, because all three are views of the same APIs. They used to be scattered across two unrelated groups.
• The public registry opens in a new tab. It’s a different surface with its own chrome, and loading it inside the dashboard read as something breaking.
• MCP usage moved to Insights, next to Analytics — it’s something to read, not something to configure.
• “Webhooks” is now “Notification recipients”, which is what that page has always actually managed.

Consumers and grants, explained

Two words for related things, neither of which said what it was. A grant is permission for your team to call someone else’s API. A consumer is a team using yours — which is what a team becomes once its grant is approved. Both pages now say so, and link to each other.

GitHub integration

• “Manage on GitHub” works for organisation installations. It was sending you to the personal-account settings URL, which 404s for an org — so it was broken for exactly half of all installations and fine for the other half.
• The page shows which repositories Spec0 can see, and how many specs are watched in each. It previously offered to add repositories without ever showing which ones had been added.
• A connected integration says it’s connected, separately from whether its checks are passing — a fresh install with nothing checked yet no longer reads as broken. A suspended installation now says it’s suspended instead of reporting itself as connected.

Until today every mirrored API sat under one shared path — /registry/public-apis/intercom-api. That prefix was the name of a bucket on our side, and it had no business being in the address of a page about somebody else’s API.

• The vendor is the address now. /registry/stripe/api, /registry/ups/shipping-api, /registry/google/maps-platform.
• The API name stopped repeating the vendor. intercom/intercom-api said Intercom twice and left nowhere to put a second Intercom API. Each listing is now named for the API: orders-api, connect-api, maps-platform.
• /registry/stripe is a page worth visiting — the APIs Stripe publishes, with their name and their logo, rather than a passthrough to a single child.
• Every old link still works. All thirteen redirect permanently, including the changelog and reference pages and the Markdown summaries agents fetch.

Nothing about a listing changed — same specification, same weekly re-read, same changelog, same subscriptions. Only the address.

Every listing now shows how it scored, and what the score is made of. A specification with no structural problems and a few hundred missing parameter descriptions reads very differently from one with broken references, and the page now says which it is rather than showing a bare number.

Around the dashboard

• Navigation grouped by what you’re doing, in the sidebar and in Settings, which is now a directory rather than a second set of links.
• Empty, loading and error states are consistent everywhere, so a screen that’s still fetching no longer looks like a screen with nothing in it.
• The GitHub integration page is rebuilt around check health over time, and has a proper first-run state before the app is installed.

A mirrored listing is still never shown as verified. Domain verification says a publisher proved who they are, and on these pages the publisher is us, not the vendor. Each one names its real owner and says plainly that we are not affiliated.

Stripe, Intercom, Twilio, Okta, Adyen, Google Maps and seven more — mirrored from each vendor’s own repository, re-read every week, and free to read without an account.

• Browse the registry — every API, grouped by owner, with search and filters.
• A changelog for each one. We re-read every specification weekly and diff it against the last. Intercom’s latest version has 66 changes that may not be compatible with code already calling it, across two endpoints — each one linked to the commit behind it.
• Email alerts. One field, no account. One message a week, only in a week where something moved.
• Your own mock server, free, generated from any listed API. Real responses, error paths you can pick, and a log of every request. It follows the listing, so it never goes stale.
• Readable by agents — there’s an llms.txt and a plain-Markdown summary per API.

One deliberate bit of wording: we say a change may be incompatible, never “breaking”. A diff between two snapshots of someone else’s specification can’t tell a real breaking change from a vendor fixing a spec that was wrong — and we’d rather be right than dramatic.

Reading, searching and subscribing need no account, and never will.

When Spec0 checks a pull request, it runs two separate checks: one for breaking changes, one for lint. The Checks tab on an API showed both results but gave you one link, and that link always opened the lint check. If breaking changes failed, you could see that it failed and there was no way to get to what broke.

Now each result opens its own findings. Click the breaking-change result, get the breaking changes. Click lint, get the lint errors.

A check that couldn’t run no longer looks like it passed. Sometimes Spec0 can’t check — there’s no earlier version to compare against, the spec file wasn’t in that commit, the pull request came from a fork, or a checking service was down. Those produce no findings, and the check detail page was reading that as “nothing wrong” and showing a green tick saying No issues found. So “we never checked this” and “this is fine” looked identical. They don’t any more: the result says the check didn’t run, and says why.

Each row is one commit. Rows now show the commit they describe. If you push again and only one of the two checks re-runs, the other says so instead of showing you its answer from the previous push — which was about a different version of your spec.

Two small additions: a check still in progress says so rather than looking inconclusive, and a check that didn’t run on a commit says “not run” instead of leaving a blank.

One note on the “why” text: Spec0 wasn’t recording the reason a check came back inconclusive — it only ever went to GitHub. Checks from now on will carry it; older ones will say the check didn’t run without the detail.

Last release added somewhere to report a problem: a feedback button in the app, and a contact page for everyone else. Both existed. Neither was easy to find, and the contact form did not work at all.

Support is now in the navigation, not just the footer — on this site and in the docs. There’s also a Support page in the docs explaining where a given report should go: the platform through the in-app button or the contact form, and the CLI, mock server or Studio through issues on their own public repositories, which are searchable and usually faster. /support goes to the same place as /contact, so either guess works.

And the contact form works. Since it launched, every genuine message sent through it failed — the server rejected it, and nothing reached us. Two separate faults, found by finally testing the whole path from the outside instead of trusting that each piece worked: requests from spec0.io without the www were blocked by the browser before they were even sent, and everything that did get through hit a server error. Automated spam, as it happens, was the only thing the form accepted, because it took a different route through the code.

If you sent us something through the contact page and never heard back, we never got it. That was not us ignoring you, and it is worth sending again — it works now, and we checked from the outside this time.

The in-app feedback button was never affected.

One sentence is still enough. The page you were on and your account come along automatically.

Published APIs in the public registry were reachable, but only if you already had the link. Nothing pointed at them, there was no sitemap, and no robots.txt — so a page nobody links to is a page nobody finds.

• A sitemap listing every published org and API, with last-modified dates, refreshed hourly.
• A robots.txt that opens the registry to crawlers and explicitly keeps them out of the signed-in routes.
• Canonical URLs on org and API pages. The registry answers on more than one address today, and without this those addresses compete with each other in search results rather than adding up.
• Structured data (schema.org/WebAPI) on every API page — for rich search results, and for the agent crawlers that a public API registry most wants to be legible to.

None of this changes who can see what. Public APIs are opt-in public; this makes the ones already public possible to find.

If you hit a bug in spec0, there was nowhere obvious to say so. The CLI, mock server and Studio take issues on GitHub, but the platform itself doesn’t, and the docs pointed nowhere. The honest answer was “find an email address and hope”.

There’s now a Feedback button in the app, in the sidebar on every page. One sentence is enough — the page you’re on and your account are attached automatically, so you don’t have to describe where you were or who you are.

And a contact page for anyone not signed in, linked from the footer of every page on this site. Give an email address and a message; a reply comes back to you, from a person.

Both reach us the same way. Neither is a ticket queue.

If you’re using the CLI, mock server or Studio, an issue on the relevant repository under github.com/spec-0 is public and searchable, and often the faster route.

Two things made publish-time governance weaker than it looked.

It was off unless you turned it on. Every policy section defaulted to off, so an organisation that had never opened the governance settings got no breaking-change protection — and was never told it was missing. Breaking-change checks now default to a warning for everyone. You still see the publish go through; you just also find out that it broke someone. If you have deliberately turned the check off, that stays off.

It failed silently. If the service that detects breaking changes was unavailable, the check was skipped and the publish proceeded as though it had passed. A check that stops checking whenever something is down — and says nothing — is not a check.

Now an unavailable checker reports that it could not run, at whatever strength you have set. On warn you are told; on block the publish is refused rather than waved through. The message always says the change could not be checked — never that a breaking change was found, because that would be a different untruth.

If you have set breaking-change to block, note the trade you are making: the checker becomes a hard dependency of publishing, so if it is down, those publishes stop. That is the point of blocking, and it is why the default is a warning.

Notification email used to be sent to whatever address someone typed into team or organisation settings. That address was never checked, so it could be anyone’s — and nothing stopped an organisation from pointing spec0 at an inbox that had never asked to hear from it.

Notifications now go to your team’s members, each at the address they verified when they signed up. Nothing to configure and nothing to verify a second time: if you can sign in, you can be notified.

• Every notification email carries a one-click unsubscribe. Your mail client’s own Unsubscribe button works, and it takes effect immediately — including on messages already queued.
• The Email toggle in your notification settings now actually works. It was previously stored and ignored, so turning it off did nothing. It does what it says.
• Subscribing to an API’s events needs a verified address. If yours isn’t verified yet you’ll be told, rather than quietly subscribed to something that could never reach you.
• Unsubscribing turns off email only. Your in-app inbox is untouched — opting out of being emailed isn’t the same as opting out of being told.

Slack delivery has been removed for now. It was unused, and it will come back properly rather than as a webhook field nobody filled in.

If your organisation had notification emails configured under Settings, those addresses are no longer used. Team members receive notifications directly instead. Shared aliases like api-team@company.com are coming back once we can confirm you own the domain.

Most API clients ask you to describe your API twice: once in the spec you already own, and again as a collection you maintain by hand and that drifts the moment the API changes. spec0 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.

Download it for macOS. It’s free, MIT licensed, and works entirely with no account — opening specs, browsing operations and schemas, firing requests, checking responses, environments and history all work offline. Connecting a spec0 organisation adds your team’s catalog and hosted mocks on top; signing out reverts to local and loses nothing.

• Schemas are a first-class tab, not something buried inside a request — with merged allOf fields, what references what, and an interactive graph.
• Read the document as text or as a rendered reference. Two tabs over the same spec: the raw YAML or JSON exactly as you imported it, and the same document rendered the way the dashboard renders it. Both work offline, and the renderer never makes a network request — so opening someone’s spec can’t tell them you did.
• Requests carry no browser origin. They execute natively rather than in a webview, so there’s no CORS preflight and no proxy needed to reach your own API — along with per-host certificate trust, proxy support, and per-API cookie jars.
• Publish a local spec straight to spec0 from the document header, the same operation spec0 push performs from CI. Studio never picks the version number for you, and won’t send a commit id for a file with uncommitted changes.
• See how many consumers an API has without leaving the app, and click through to the dashboard for who they are.

The app is signed and notarized by Apple, so it opens without a Gatekeeper warning, and every release publishes SHA-256 checksums alongside the download.

Elsewhere in this release:

• The schema graph stays usable on large specs. The canvas is navigable on documents that previously made it unmanageable, and it now survives hostile or malformed OpenAPI documents instead of hanging on them.
• Fixed: one unparseable spec could stall indexing for an entire organisation. Ingestion failures are now isolated per API, so a single bad document no longer strands everything behind it.

A mock server was built from the spec it was created with. Publish a new version of the API and the mock quietly kept serving the old contract — which isn’t just stale, it makes any tool comparing responses to the spec report differences that aren’t real.

You can now rebuild a mock against the API’s current spec. Its id, URL and API key stay the same, so nothing pointing at it needs to change — CI config, exported shell variables, teammates’ bookmarks all keep working. Its request logs, environment variables and per-operation settings come across too, and any hand-written response variants are carried over where their operation still exists. If one couldn’t be carried, you’re told which, rather than losing it quietly.

• Use the token you already have. Mock servers now accept a normal Spec0 personal or service token alongside the mock’s own X-Mock-API-Key, so scripts that already authenticate to Spec0 don’t need a second credential.

The schema registry gave you every shape across your APIs, searchable and drawable. Your agents couldn’t see any of it — they could list endpoints and read specs, but not answer the question that actually matters when someone proposes a change: what else uses this shape, and what would break?

They can now. The same registry is queryable over MCP: look up a schema by name, read its shape, and ask what depends on it. Component names are namespaced per API, so two teams can both have a Customer without one shadowing the other in an agent’s answer.

• Tag schemas, and get domains for free. The tags you apply roll up into domains, so “everything in Billing” becomes something you can ask about rather than a naming convention everyone has to remember.
• Every org-scoped answer names its organisation. If you belong to more than one, an agent’s reply now tells you which one it covered instead of leaving you to work it out.

More in the MCP tools reference.

Access to an API was all or nothing. A grant can now be scoped to individual operations, so a consumer that only needs to read orders doesn’t get everything else in the same API alongside it.

When we renamed subscriptions to grants, we said the old word was doing two jobs — I depend on this API and tell me when it changes. Those are now genuinely separate. You can follow an API’s events without holding a grant to call it, which means keeping an eye on something you’re evaluating no longer means asking its owner for access you don’t need yet.

• Specs are checked at every entry point. Anything that isn’t valid OpenAPI 3.0.x or 3.1.x is rejected wherever it arrives — CLI, GitHub import, or upload — instead of being accepted and failing confusingly further down.
• Quality scores record which ruleset produced them. A score no longer silently means something different after you change your rules.
• Fixed: a newly created API records its first version straight away, so it shows up in the schema registry immediately instead of waiting for a second publish.

Requesting access to another team’s API has always ended in an approval. Now the approval itself is governed.

• Name your approvers. Each API can carry an explicit list of grant approvers, set on the API’s Permissions tab. If you don’t set one, the owning team’s admins remain the approvers — the previous behaviour, now as the explicit fallback.
• No self-approval. Whoever requested a grant can never be the one who approves it, even if they’re on the approver list.
• Auto-approval only when review would be theatre. If you request access to an API your own team owns, or there is genuinely no other person who could review it, the request approves automatically — and is recorded as auto-approved with the reason, so the audit trail stays honest.
• Rejections notify the requester. Consumer teams now get a notification (and email) when a request is turned down, instead of a request that silently never progresses.

Pending requests show who they’re waiting on, and approved ones show whether a human or the auto-approval rule let them through.

Your APIs’ schemas were always in the specs — but answering “which of our APIs carry a tax_id field?” or “what does this payload actually reference?” meant opening spec files one by one. The new Schema registry in the sidebar answers those questions directly.

• One directory for every schema. Each component schema from every API’s latest version, in one searchable list. Search matches schema names and field names, so “which APIs have a tax_id” is one query.
• Duplicate shapes, surfaced. Schemas with structurally identical shapes are grouped automatically — a ×3 chip means this exact shape lives in three places, and each schema’s page links to its twins. Renames, formatting, and $ref factoring don’t fool the comparison; it’s the resolved shape that counts.
• A page per schema. Fields with types and descriptions, the raw definition with one-click copy, which operations carry the schema, and which sibling schemas reference it — the blast-radius view before you change anything.
• A graph for every API. Open any API as a drawing board: it starts on the most connected schema, a click shows a schema’s description and fields, another click expands its neighbours, and an operations toggle shows which endpoints carry each shape. Reachable from the directory, from any schema page, and from the API’s own header.

Pointing your coding agent at your API catalog used to start with installing our CLI. It doesn’t any more — Claude Code can add a remote MCP server natively, and that’s now the first thing we offer you.

• One line, no dependency of ours. Copy the claude mcp add command from your home screen and paste it into a terminal. Claude Desktop gets the config block it needs instead, since it has no equivalent command.
• The CLI is still there if you want it. spec0 setup does everything in one step — auth, MCP server, and the Claude skill — and it’s now offered as a choice rather than the only route.
• You can see whether it actually worked. The card shows whether you’re connected, and it only says so once your agent has genuinely made an authenticated call. Adding the server and signing in are two separate steps, and the card tells you that up front instead of leaving you wondering why the tools say you’re unauthenticated.

There’s a “How this works” link that opens the agent docs without navigating you away from what you were doing.

Bringing your own LLM key meant pasting a credential into a form that never explained what would happen to it. That page now leads with the answer.

• Three plain statements up front: the key runs on your account and bills there, we record token counts per feature but never the content of prompts or responses, and you can revoke it whenever you like.
• The features that will use it are listed, so you know what you’re switching on.
• Direct links to the provider console for Anthropic and OpenAI, so you’re not hunting for the page that issues the key. Bedrock and Azure link nowhere rather than somewhere misleading — they have no single equivalent page.
• The explanation opens in place. Reading it doesn’t cost you the half-filled form you were in the middle of.

We also fixed a set of links that pointed at a settings page that doesn’t exist — including the one shown to people who have no key configured yet, which was exactly the wrong moment for a dead end.

If you’ve just signed up, the first screen should tell you what to do — and ours was pointing at a demo. This release rewrites that first run.

• The home screen leads with your own API. Uploading a spec, importing from GitHub, and pushing from the CLI are all offered up front, with the CLI command right there to copy. The sample petstore is still one click away if you’d rather look around first.
• Every step in the getting-started checklist is now a link to the page that completes it, and you can dismiss the checklist once you’re done with it.
• Your inbox opens with a short guide. It reads from the same signals as the checklist, so it knows what you’ve already done and only points at what’s left.
• If you were invited to an organisation but not yet added to a team, creating an API used to present a disabled button with no explanation. It now tells you what’s missing and who can fix it.

We also removed a product tour that had stopped working — several of its steps pointed at parts of the interface that no longer exist, and once dismissed it never came back.

The Agent readiness score on your home page was a stand-in: every API that passed linting showed the same number, so comparing two APIs told you nothing and the score gave no hint about what to improve.

It now reads your published spec and scores three things that decide how usable an API is to an AI agent:

• Descriptions (40%). An agent picks an operation by reading its summary. An unnamed operation is effectively invisible to it.
• Examples (40%). One concrete request or response example does more for payload accuracy than a schema alone.
• Non-deprecated operations (20%). Deprecated operations still in the document are ones an agent can and will call.

The card shows each factor with its score and the counts behind it — “12 of 30 operations” — so “why is it 61” is answerable without leaving the page. The per-team Readiness column in analytics uses the same scorer, so the two views can’t disagree about the same API.

An API with no published spec now shows ”—” rather than a score. We’d rather say unknown than put a low number next to an API nobody has published yet.

If you’ve read our governance docs recently, you’d have come away thinking breaking-change policy was something we planned to build. It has been running on every publish for months. That was our mistake, and it’s fixed.

Governance now documents what actually ships: five policy sections — breaking change, naming, required fields, versioning, and spec sources — each evaluated server-side on every publish, each with its own mode:

• Off — not evaluated.
• Warn — surfaced at publish time, but the publish succeeds.
• Block — the publish is rejected.

The page now also documents what a rejection looks like end to end: the HTTP status, the error payload, and the CLI exit code, so you can wire it into CI without reverse-engineering it. It’s honest about the limits too — the breaking-change check fails open if the diff engine can’t run, so it’s a strong guardrail rather than a proof of compatibility.

We’ve also added a check to our own build that fails when a “coming soon” claim in the docs passes its review date. Our docs are served directly to coding agents through Spec0’s MCP tools, so a stale page doesn’t just misinform a reader — it misinforms the assistant sitting in your editor.

“Subscription” was doing two jobs at once — I depend on this API and notify me when it changes — and neither reading was obvious from the word. Now they’re separate ideas with separate names.

• A grant is the approved permission for one team to call specific operations on another team’s API. It’s what a producer team’s admin reviews and approves.
• A consumer is the team holding that grant.
• Subscribing now means only one thing: opting in to notifications.

You’ll see the new wording across the dashboard, and the Subscribers page is now Consumers. Nothing about your existing access changed — the same teams have the same permissions on the same operations, under clearer names. Roles and permission settings are unchanged.

This also sets up work we’re building next: because a grant records exactly which operations a team was approved for, it can drive things like scoped tooling and precise blast-radius answers when an API changes.

Connecting a repository used to work only if your API document was named openapi.yaml. A repo with swagger.json, api.yml, or docs/api.yaml came back as “no specs found” — and your first real interaction with Spec0 was typing a file path by hand.

• We now recognise the conventions projects actually use. swagger.*, api.*, spec.*, orders-api.yaml, openapi.v1.yaml and the rest are found, while package.json, tsconfig.json, generator configs, and anything inside node_modules, vendor, dist or test fixtures stay out of your way.
• The list is ordered by how likely each file is to be the one you meant — an exact openapi.yaml at the repository root comes before a candidate buried four directories down.
• You can browse the repository. If your spec is somewhere we didn’t guess, or the repo holds several and you know which one you want, open the file browser and pick it. It filters to YAML and JSON by default, has a search box, and can show every file when you need it.
• The branch you choose is now the branch we read. The source-branch field was previously ignored when scanning for files — if you pointed Spec0 at a branch other than the default, it quietly looked at the default anyway. It doesn’t any more.

Whatever you pick is validated as a real OpenAPI document before the wizard moves on, so a wrong file tells you immediately instead of failing at the end.

Strict validation used to check the JSON request body and nothing else, so a request that omitted a required query or header parameter still got a normal response. That made the mock more forgiving than the real API it stands in for — the opposite of what you want from a contract test.

If a mock is set to Strict, it now also rejects requests missing a required query, path, or header parameter.

This is a behaviour change worth knowing about: a caller that was quietly omitting a required parameter will start getting rejections. That is usually the bug the mock exists to catch — but if you’d rather not enforce it yet, the mock’s Request Validation Mode setting has Lenient and Disabled options.

Mocks on the default Lenient mode are unaffected.

An OpenAPI spec describes one API in isolation — it can’t tell you who owns it, who depends on it, or what breaks if it changes. Spec0’s MCP server, and the Ask Spec0 chat, can now answer those by reading your organisation graph:

• Who consumes this API? The owning team, the subscribers, and each consumer’s team and status — so an agent can reason about the blast radius of a change before you make it.
• What does a team own and depend on? A team’s APIs, the APIs it consumes, and its members — in one call.
• A lay of the land. Team, API, and service totals with per-team ownership and consumption counts, to orient before drilling in.

These join the existing ownership lookups — who you are, who owns a given API, and which teams you’re on — so an agent has both the “who owns what” and the “who depends on what” directions of the graph.

See the Agents & MCP docs for the full tool list.

This release cleans up several things you told us about:

• Environments show their APIs. Opening an environment’s page now lists every API configured for it and the URL it serves at, instead of always reading “0 APIs configured.”
• Notifications persist. Alerts stay in the notification bell until you’ve read them.
• Generating a changelog keeps your draft. The AI changelog generator no longer wipes text you’d already written in the body.
• Correct team dates. Teams show their real creation date, not January 1970.
• Commit links go to GitHub. Clicking a commit opens it on GitHub, not a dead in-app route.

The home used to withhold the operational dashboard until you personally had connected both the CLI and the MCP server — so an admin with a fully set-up organisation could still be stuck on a “connect your CLI” nudge. That’s fixed. If your organisation has APIs, you land on the operational home; connecting your own tools now personalises it rather than blocking it.

• A “needs attention” worklist. The specs and APIs that need a look — gathered in one place, scoped to your team’s APIs, most important first.
• An agent-readiness signal. An at-a-glance score for how ready each of your APIs is for agents to consume, with a per-API breakdown.
• Honest status chips. The header shows your real MCP, CLI, and GitHub connection state — each unconnected one links straight to its setup page — instead of pretending everything is wired up.
• For org leads. Holders of the analytics role get a new organisation-wide view at /analytics, rolling up API coverage and per-team governance across the whole org.

Everything reads in plain language, and anything we can’t compute yet says so plainly rather than showing a hollow zero.

Inviting someone to your organisation now sends them a Spec0 email with an accept link. It works whether they’re brand new to Spec0 or already have an account in another organisation — accepting simply adds your organisation to the ones they belong to, and they keep the one they already had.

Pending invitations are now manageable, too. If an invite expired or got lost, resend it; if you invited the wrong address, cancel it to free that email up to be invited again. Both live on Settings → Members, next to each pending invite.

Spec0 used to tie every account to a single organisation. Now you can belong to several — your own, your company’s, a client’s — and switch between them from the organisation switcher next to the Spec0 wordmark. Everything you work with — APIs, teams, mocks, members — follows the organisation you’re currently in.

Your role is per-organisation, too. You can be an admin in one and a regular member in another, with permissions scoped to wherever you’re working at the time.

This is the groundwork that also makes cross-company invitations work cleanly: being invited somewhere new no longer means giving up the organisation you already have.

The first time you sign in, Spec0 now asks you to name your organisation instead of dropping you into a placeholder “My Organization”. You can invite teammates right there in the same step, or skip it and do it later.

From there, a getting-started checklist walks you through the core path — publish your first API, connect an AI agent over MCP, spin up a mock, and invite your team — so there’s always an obvious next step rather than a blank dashboard.

The docs now have a guided walkthrough that sits alongside the fast-path quickstart. Where the quickstart is just the commands, the walkthrough explains the why behind each step and the decisions you’ll face.

It covers the whole journey in order: creating a team and what teams are for, installing the CLI, publishing your first API, connecting an AI agent over MCP (with example prompts), setting org-wide governance rules, adding Spectral lint quality gates in CI, spinning up a mock, and finally opening an API to the public registry.

We’ve also dropped recommendations in as you go — the biggest one: let Git drive publishing rather than pushing specs by hand. Your registry stays correct by construction, and breaking changes get caught in the PR that introduces them.

The post-login home used to show every panel to everyone, whether you’d published nothing or run the platform for months. It now detects where you are and shows one focused layout with a single primary action:

• Just starting? You get a short getting-started checklist and a sample Pet Store API to explore — no blank account, ever.
• Have APIs but no agent connected? You get copy-paste snippets to wire up the MCP server and CLI, plus a look at what your org has already published.
• Fully set up? You get the part that matters day to day: changes in the APIs you depend on, your governance quality score, and a quiet summary of recent activity.

Everything reads in plain developer language — “+2 endpoints, 1 breaking” rather than “version published” — so the feed tells you what actually changed.

We expanded what your coding agent can do over the API Registry MCP:

• Ownership & identity. Agents can find out who owns an API and which team is responsible, and confirm the identity of the org they’re connected to. “Who owns the payments API and what’s its quality score?” now has a real answer.
• Operation & component search. Instead of pulling a whole spec, agents can search for the exact operation or schema component they need and read just that.
• Bounded spec reads. Fetching a full spec is now size-bounded, so a large API doesn’t flood the agent’s context. Most questions resolve in a few hundred tokens instead of tens of thousands.

The net effect: agents answer more questions, more precisely, while using a fraction of the context they used to.