Sync your architecture

Keep your docs in sync with reality.

Architecture docs go out of date the moment something changes. EventCatalog keeps them current: AI agents update your catalog as your code changes, and integrations generate it from your specs and schema registries.

Get started Explore integrations

Any model, your own keys
Your code and docs stay private
Your own workflows

orders-service#231Merged

Publish OrderShipped when an order ships

src/shipping/ship-order.ts

+ await producer.send('orders.events', {+ type: 'OrderShipped',+ orderId, carrier, trackingId,+ });

Code-to-Docs

Read the change
Plan the impact
Update the docs
Check and open PR

your-catalog#88Waiting for agent

+events/OrderShipped/index.mdxnew event
~services/OrdersService/index.mdxnow sends OrderShipped
~channels/orders.events/index.mdxnew message

Only the docs this change affects. You review and merge.

Trusted by teams at

Docs drift because keeping them current is nobody’s job.

Every architecture catalog starts accurate. Then the code moves on, and the docs don’t. EventCatalog keeps them current from the places your architecture actually changes.

From your code

EventCatalog Agents read each pull request across your organization and update the docs it affects.

How the agents work

From your specs

OpenAPI and AsyncAPI files generate your services, messages and schemas, and regenerate them when the spec changes.

Spec integrations

From your schema registries

Confluent, Apicurio and other registries keep your message schemas current, where they already live.

Registry integrations

Your code changes. AI agents update the docs.

EventCatalog Agents connect your repositories to your catalog. Each change that affects your architecture comes with an update to your docs, as a pull request for your team to review.

1. Code changes

A pull request merges in one of your repositories: a new event, a changed schema, a new data store.

2. The agent updates your catalog

It works out which docs the change affects and updates them, in your catalog’s structure and style.

3. Your team reviews

The update arrives as a pull request in your catalog. Merge it, edit it, or close it.

eventcatalog-agentsbotcommented

📘 EventCatalog docs updated

Opened acme/catalog#23 to keep the catalog in sync with this pull request.

Change	Resource	Files
Updated	Event `PaymentSucceeded`	`index.mdx`, `schema.json`, previous version `1.0.0` archived
Updated	Service `StripeWebhookEndpoint`	`index.mdx`

Worth checking

Noticed in the catalog but not changed: Checkout API consumes PaymentSucceeded in code, but its receives doesn't list it.

EventCatalog Agents · Code-to-Docs · reviewed 5 changed files · catalog acme/catalog@main

Bring your own model

Use any model you want, such as Claude, GPT or a model on Amazon Bedrock, with your own key. You pay your provider directly.

Your data stays private

The agents run in your own CI. Your code goes only to the model provider you choose. We never see your code or your catalog.

Set up your own workflows

Decide which repositories update which catalog, whether updates happen on merge or in review, and who approves them.

Set up the agents How the agents work

Shaped around how your organization works.

One catalog for the whole organization, or one per team combined with Federation. The agents run where your code lives and update the catalogs your teams already own, on merge or during review.

One catalog for the organization

orders-servicepayments-serviceinventory-service

acme/catalog

A catalog per team, with Federation

orders-servicefulfilment-service

orders

payments-servicefraud-service

payments

Organization

Set up in your organization About Federation

Your specs and registries, generated into your catalog.

OpenAPI, AsyncAPI and your schema registries already describe much of your architecture. EventCatalog generates those parts directly and keeps them in sync, and the agents keep up with everything no specification describes.

AsyncAPI

Event-driven APIs

Your AsyncAPI files become services, channels and messages, with producers and consumers connected and a page for every message.

Read the AsyncAPI docs

orders-service.asyncapi.yml

asyncapi: 3.0.0

info:

title: Orders Service

channels:

orders.events: { bindings: kafka }

operations:

sendOrderCreated: { action: send }

receivePaymentTaken: { action: receive }

EventCatalog

Architecture Diagram

EventPaymentTaken

ServiceOrders Service

EventOrderCreated

Kafka channelorders.events

Documentation

EventOrderCreatedv1.2.0

ProducerOrders Service

Kafka channelorders.events

SchemaOrderCreated.avsc

OrderCreated.avscAvro

{
  "type": "record",
  "name": "OrderCreated",
  "fields": [
    { "name": "orderId", "type": "string" },
    { "name": "customerId", "type": "string" },
    { "name": "amount", "type": "double" },
    { "name": "currency", "type": "string" },
    { "name": "createdAt", "type": "timestamp-millis" }
  ]
}

OpenAPI

REST APIs

Your OpenAPI files become a documented service with its commands and queries, visualized, with the spec rendered alongside.

Read the OpenAPI docs

Schema registries

Confluent, Apicurio, GitHub and more

Schemas only tell half the story. Keep them where they live today, and let EventCatalog add the meaning: what each message is for and who depends on it.

Read the registry docs

Confluent Schema Registry

Apicurio Registry

GitHub

Your own registryvia the SDK

EventCatalog

Documentation

EventOrderCreatedv3

added in EventCatalog

Raised when a customer’s payment clears and the order is confirmed. Starts fulfilment and invoicing.

DomainOrders

OwnerOrders team

ConsumersBilling, Fulfilment

DecisionADR-012

OrderCreated.avscAvro · v3synced from your registry

{
  "type": "record",
  "name": "OrderCreated",
  "fields": [
    { "name": "orderId", "type": "string" },
    { "name": "customerId", "type": "string" },
    { "name": "amount", "type": "double" },
    { "name": "currency", "type": "string" },
    { "name": "createdAt", "type": "timestamp-millis" }
  ]
}

Sync from where they live

Point at a file, a URL or a schema registry, and regenerate from CI/CD whenever something changes.

Versioned with your specs

Each spec version becomes a catalog version, so history is never lost.

Your writing is kept

Context you add in markdown survives every regeneration.

See all integrations Build your own with the SDK

Your teams write the why. EventCatalog keeps up with the what.

The best catalogs mix both. People document what code can’t tell you. Agents and integrations keep the parts that change with every commit accurate, on the same page.

Your teams write the why

What a domain is for, its language, the decisions behind it, and who to ask. Only people know this.

Agents and integrations keep up with the what

What each service sends and receives, its schemas and specifications, kept current from your code, specs and registries.

Both, in the same catalog

Agents follow what your teams wrote and leave it as it is. Your teams review and refine every change.

Service

Payment Worker

SummaryDrives charges and refunds against the payment processor.Your team

Ownerspayments-platformYour team

Receivespayment-succeeded 1.0.0, payment-failed 1.0.0Agents

Sendspayment-requested 1.0.0Agents

Writes topayment-databaseAgents

Specificationopenapi.yml, updated in #23Agents

Why it exists

Stripe confirms payments asynchronously. The worker turns those callbacks into our own events, so Checkout never talks to Stripe directly.

Your team

Stop your docs drifting from reality.

Connect your first repository or spec in a few minutes, and let your teams focus on the context only they know.

Get started Explore integrations