Documentation

Documentation built around your architecture.

Not another wiki page. Document the domains, systems, services, messages and flows your architecture is built from, each with an owner and its relationships, versioned in Git and kept in sync with your specs.

Start documenting View the demo

EventCatalog documentation for the Payment Processing system, with its resource diagram

Trusted by teams at

Architecture primitives, not pages.

In distributed systems, if you can't find it, it doesn't exist. Every part of your architecture gets its own page, owner and relationships, so teams can reason about change before it breaks something.

DomainsBusiness boundaries and the language used inside them.SystemsGroups of services that deliver one capability.ServicesWhat each service owns, sends and receives.MessagesEvents, commands and queries, with their schemas.ChannelsTopics, queues and routes on any broker.FlowsBusiness processes, step by step across services.EntitiesThe domain model behind your messages.Data storesDatabases and the services that read and write them.Teams and ownersWho owns what, and who to ask.DecisionsADRs linked to the resources they shape.

Payment APIServiceSearch EventCatalog⌘K

Service

Payment APIv1.0.0

Receives payment authorisation requests from the Ordering domain and records the payment intent.

Ask a questionCopy as markdown

Overview

The Payment API is the entry point to the Payment Processing System. It receives Authorize Payment, records the intent in the Payment Database and leaves the Payment Worker to charge Stripe.

Custom properties

Operational tier1

Cost centrepayments-engineering

On call#payments-incidents

Find what exists. Find who owns it.

One place to search your architecture, from the domain down to a single field in a schema.

Searching for order in EventCatalog and exploring the Create Order command's schema properties

Search everything

Type “order” and see every command, event and query that matches, with the service that owns it.

Ownership on every resource

Every page shows who owns it, so questions reach the right team first time.

One catalog for every role

Developers find schemas, architects trace dependencies and product teams follow business flows.

Any spec, any schema, with the context around it.

Specifications describe the shape of your APIs and messages. EventCatalog adds what they leave out.

Bring what you already have

OpenAPI, AsyncAPI, GraphQL, Avro, Protobuf and JSON Schema, each wrapped with ownership, relationships and diagrams.

Version every spec

Every version is kept, so you can compare releases and see when a breaking change arrived.

No more spec sprawl

Specs from different repos, teams and registries show up in one catalog, assigned to a domain and an owner.

See how syncing works

An OpenAPI specification rendered in EventCatalog

ADRs, runbooks and RFCs, next to what they describe.

Bring your team's documents into the catalog and link each one to the resources it affects. No more hunting across Confluence, Notion and old repos.

Read about custom docs

ADR-012: Version all public eventsADR

Every public event carries a version, and breaking changes ship as a new version.

Architecture team·Linked toOrderCreatedOrders domain

Payments Service deploymentRunbook

Step-by-step guide for releasing and rolling back the Payments Service.

Payments team·Linked toPayments Service

RFC-021: API versioning strategyRFC · Draft

Proposal for standardising API versioning across every service.

Platform team·Linked toPayments APIOrders API

Turn architecture decisions into checks.

Your team agreed how the architecture should look. Fitness functions check that it still does, so a change that crosses a domain boundary or adds one dependency too many is caught in review, not six months later.

Rules as code

Write each rule as a TypeScript function that reads your catalog with the EventCatalog SDK. No new query language to learn.

Owned where they live

Keep catalog-wide standards at the root, and let each domain team keep its own rules next to its domain.

Checked on every change

Run the checks locally or in CI. A change that breaks a rule fails the build, and points at the resources that broke it.

Read about fitness functions

fitness/event-ownership.fitness.ts

import { defineFitnessFunction } from '@eventcatalog/fitness';

export default defineFitnessFunction({
  id: 'event-ownership',
  name: 'Every event has an owner',

  async run({ catalog }) {
    const events = await catalog.getEvents({ latestOnly: true });

    return events
      .filter((event) => !event.owners?.length)
      .map((event) => ({
        message: `${event.name} has no owners`,
        resources: [{ type: 'event', id: event.id }],
      }));
  },
});

Terminal

$ npx eventcatalog fitness check

EventCatalog Fitness

✓ ordering / Domain boundaries    Passed
! order-service / Loose coupling  1 warning
    • Order Service has 6 dependencies (the limit is 5)
      Resources: order-service (service)
✗ Every event has an owner        1 violation
    • Order Amended has no owners
      Resources: order-amended (event)

3 fitness functions evaluated

Ask your documentation anything.

Your catalog is a structured graph, so AI answers from real relationships, not guesses. Ask in the catalog with EventCatalog Assistant, or from your IDE through the MCP server.

Set up the MCP server All agent integrations

Claude

OpenAI

CursorAny MCP client

Your agentconnected to EventCatalog MCP

›

›Ask about your architecture…scope: orders domain

Document one domain today.

Start with a single domain in Markdown, or generate it from your specs. Free for organisations under $10M.

Start documenting Book a demo