What's new in Spec0.

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.