What's new in Spec0.

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.