Custom governance workflows
EventCatalog is technology-agnostic and lives as docs as code.
Shape governance to fit your architecture—not the other way around.
Governance isn't one-size-fits-all. Some teams want every new producer or consumer to flow through a pull request. Some want their schema registry to stay the source of truth for engineers, while product and analysts work in a curated catalog. Some want webhooks firing every time a schema breaks. Most want all of the above—just configured a little differently.
Because EventCatalog lives as docs as code in a Git repository, you can build any CI/CD workflow you want around it. Pull requests become governance gates. CI builds rebuild the catalog. Webhooks fan out to the systems that care.
The result: governance shaped by your architecture, your teams, and your existing tooling—not by what some product happens to support.
Designed to be extended
Plug in your CI, your registries, your IDPs, your webhooks, your AI agents. EventCatalog provides the model and the glue—you decide the workflow.
Patterns we see in the wild
How real teams shape governance with EventCatalog
These aren't prescriptive. They're patterns we keep seeing—usually mixed and matched to fit each org.
Pull-request governance
EventCatalog is the entry point for adding producers, consumers, services, or events. Changes flow through PRs reviewed by architects and domain owners.
- CODEOWNERS enforce who reviews what
- Catalog lint as a CI check
- Auto-deploy on merge
Webhook-driven downstream
When producers or consumers come and go, or schemas break, the catalog fires webhooks into the systems that care —Slack, Jira, on-call, custom tooling.
- Notify consumers about breaking changes
- Open tickets for deprecations
- Trigger downstream rebuilds
Registry → catalog
Engineers keep their schema registry as the operational source of truth. EventCatalog pulls from it and adds the business context product and analysts need.
- Engineers don't change tools
- Product gets a curated, navigable view
- Analysts get business workflow docs
Pick one. Mix them. Build your own. The catalog is yours.
What makes it flexible
Three ingredients that let EventCatalog plug into almost any governance model.
Docs as code
The catalog lives in Git. Anything you can do with code—reviews, CI, templates, automation—you can do with your architecture docs.
Technology-agnostic
Use it with Kafka, Pulsar, AWS, Azure, gRPC, REST—or whatever you have. EventCatalog doesn't lock you in.
Webhooks & events
Built-in webhooks fire on the things that matter—new producers, missing consumers, breaking changes—so you can wire downstream systems however you like.
Custom integrations
Build generators against any internal tool with the SDK—your IDP, registry, IAM, or that one bespoke service running half the company.
What we recommend
Don't start with the tooling. Start with the workflow you actually want.
Sketch out the governance you wish you had: who proposes changes, who reviews them, what gates they pass through, where the source of truth lives, and who needs to be notified when things change. Then map EventCatalog into that picture.
Because the catalog is flexible by design, it tends to slot into whatever you describe—whether that's strict centralized review, fully federated team ownership, or something in between.
Want to talk it through?
We genuinely love hearing what teams are trying to do, fix, or unlock. Tell us about your governance challenges and we'll help you map out where EventCatalog fits—or share patterns we've seen work elsewhere.
Ready to design your governance workflow?
Tell us how you want governance to work and we'll show you how EventCatalog fits in—or pair you with a team that's solved a similar problem.