Events
What you can subscribe to today and where it shows up — change logs, breaking changes, and publisher announcements.
When something meaningful happens to an API you depend on, the platform tells you about it. This page covers the three event types consumers can opt into today and where they surface in the dashboard.
Iterating. The events surface is intentionally narrow in v2. We're going to add more event types, finer-grained controls, and outbound channels as customers ask for them. Treat the list below as the floor, not the ceiling.
What you can subscribe to
| Event | When it fires |
|---|---|
| Change log | A new version of an API you've subscribed to is published. The notification carries a one-line summary of what changed, computed by Spec0's diff. |
| Breaking change | The new version is breaking. Splits out from change logs because it's the one your CI almost certainly cares about. |
| Publisher announcement | A one-shot broadcast from the API owner — deprecation notices, schedule changes, anything the team running the API wants every active consumer to see. |
Delivery of these events is tied to your existing Grants — if your team holds an approved grant on an API, you're already on the receiving end of these events for that API. There's no separate "events" object to manage.
Where they surface
| Route | What it shows |
|---|---|
/inbox | Per-user feed: events relevant to the APIs your team subscribes to, plus mentions and approvals waiting on you. |
/notifications | The same feed, with read/unread state and filters. The inbox is a curated default view; this is the full surface. |
Read state advances when you view the feed; unread events fall back to the daily email digest if you don't see them in-app.
Notification preferences
Control how events reach you under Settings → Notifications (/settings/account/notifications):
- In-app inbox — toggle whether events appear in your in-app inbox (the bell in the top bar). On by default. Turn it off and you stop getting in-app notifications without touching your grants.
Email and Slack are delivered to your organisation's shared channels — configured under Settings → Integrations (Webhooks & notifications), not per person — so they're a team-level setting rather than a personal one. Per-user email/Slack controls land alongside the outbound channel work below.
Building on events
A couple of patterns worth pointing at:
- CI smoke test on publish. Subscribe to a critical upstream API and let the change-log notification trigger an integration test on each new version. Pair with the block-on-breaking-changes recipe on the publisher side for end-to-end safety.
- Slack/email out of band. The email digest covers most "tell my team" needs today; richer routing (Slack, PagerDuty, signed webhooks) lands when we ship the outbound channel. We'd rather get it right once than half-ship it three times.
What an AI agent sees
Events aren't exposed through MCP today. If an agent integration needs to react to platform changes, poll the REST surface (GET /notifications) or wait for the outbound channel above.
Where to go next
- Grants — events flow off your approved grants.
- APIs — what events are about.
- API reference — the REST surface that drives the inbox.
Access control
Roles, permissions, and the rules Spec0 uses to decide whether a request from your dashboard, CLI, or CI is allowed. What we accept, what we reject, and why.
Recipes
Step-by-step recipes for the most common Spec0 platform tasks. Each recipe declares its prerequisites and links to the recipes you need first.