EnterpriseEventCatalog Federation

Documentation that scales.
Synced and verified in one catalog.

Every team owns their documentation in their own repository, close to their code and their domain — while your organization catalog pulls, syncs, and verifies them into one connected view of your architecture.

Read the docs Book a demo

Payments

Payments Team

PaymentServiceservice

payment-capturedevent

payment-captured.avscavro

adr-payment-provideradr

own repo27 resources

Orders

Order Management

OrderServiceservice

order-completedevent

orders-api.ymlopenapi

order-lifecycleflow

own repo19 resources

Fulfillment

Fulfillment Ops

WarehouseServiceservice

inventory-reserved.protoprotobuf

shipping-events.ymlasyncapi

shipment-dispatchedevent

own repo31 resources

$ npx eventcatalog federate

Indexing 3 catalogs · 77 resources discovered

Linting ownership & relationships · 0 errors

Acme Inc

Organization catalog · one connected, validated view

77 resources · 148 relationships

Payments

Orders

Fulfillment

Organization catalog in EventCatalog showing connected architecture across teams

Trusted by engineering teams around the world

Documentation is distributed. Your view of it isn't. Your architecture is built by many teams, in many repositories. At scale, keeping one shared view accurate, owned, and up to date gets harder with every new team, service, and schema.

One repo can't keep pace with every team.

As the organization grows, coordinating every team's documentation through a single repository takes real effort — and slows everyone down.

Documentation lives far from the code it describes.

Teams keep their best documentation close to their code. Pulling it into one shared view shouldn't mean giving that up.

Teams copy each other's definitions.

Copies drift. Nobody knows which version of an event is the real one, or who to ask.

Nobody knows who owns what.

Two teams document the same service differently — and both look authoritative.

Every team's documentation is a silo.

Cross-team flows — checkout calling payments, orders triggering fulfillment — are invisible to everyone.

Merging docs by hand doesn't scale.

Scripts that clone and copy files lose provenance, break silently, and drift from their source.

Composition, not centralization.

Teams own

their docs.

One catalog

for the org.

Validated

on every run.

Always

reproducible.

How it works

Distributed docs, one connected view.

Federation is built into EventCatalog. No custom scripts, no copy pipelines — your organization catalog declares its sources and one command does the rest.

Teams keep their own catalogs

Each team documents their domains, services, and messages in their own EventCatalog, in their own repository. Nothing changes for teams — no plugins, no extra config.

Your organization catalog selects its sources

List the team catalogs you want to combine — GitHub repositories or local paths. Four lines of config per source.

Run one command

Federate fetches every source, validates ownership and relationships across the whole organization, and materializes one connected catalog.

Federate your first catalogs

eventcatalog.config.js

export default {
  title: 'Acme Architecture',
  federation: {
    sources: [
      { id: 'acme/payments', source: 'github:acme/payments-catalog' },
      { id: 'acme/orders', source: 'github:acme/orders-catalog' },
      { id: 'acme/fulfillment', source: 'file:../fulfillment-catalog' },
    ],
  },
};

terminal

$npx eventcatalog federate

Found 3 configured sources

[1/3] acme/payments: 27 resources at 4a1b7e2

[2/3] acme/orders: 19 resources at 9c31f0d

[3/3] acme/fulfillment: 31 resources

Validating ownership across the organization...

Graph resolved: 77 remote resources, 148 relationships

Federation complete: 3 sources, 214 files written

Recorded resolved source state in eventcatalog.lock

fulfillment-catalog / services / WarehouseService

---
id: warehouse-service
name: Warehouse Service
receives:
  - id: order-completed
---

resolved across catalogs

order-completed

Event · v1.0.0

owned by acme/orders

One definition, one owner. Every consumer across the organization resolves to it — no copies, no drift.

Reference, don't copy

Relationships resolve across catalogs

Teams reference each other's events, commands, and services by ID — they never copy definitions between repositories. Federation connects the pointers into one graph, so cross-team flows finally become visible.

Every resource has exactly one owner: the catalog that holds its files. If two catalogs claim the same resource, federation stops and names them both — ambiguity is a modelling error, not something to render.

Built for organizations

Federation you can trust in CI

Federation treats your organization's documentation like a build: explicit, validated, and reproducible.

Ownership, guaranteed

Every resource has exactly one owning catalog. Duplicate ownership fails the run and names both catalogs — no silent overwrites, no last-write-wins.

Validated like code

Lint-style rules catch missing resources, type collisions, and version mismatches across the whole organization. Promote warnings to errors in CI, or mute rules while you migrate.

Reproducible builds

eventcatalog.lock records the exact commit and content digest of every source. Same inputs, same catalog — every time.

Safe by default

Federation runs are transactional. If a run fails, the previous catalog stays intact — you never ship a half-written view of your architecture.

GitHub and local sources

Federate from public or private GitHub repositories, or from local paths while you develop. Test the whole loop on your machine before wiring up CI.

The central catalog is still a catalog

Your organization catalog can own cross-cutting documentation of its own — enterprise domains, flows, and architecture decisions that span teams.

Bring your distributed documentation together.