Solace AsyncAPI Support: Event Portal Export and the Event Catalogue

Solace AsyncAPI support lives in Solace Event Portal: you design applications, events and schemas, and Event Portal generates an AsyncAPI document that describes each interface in a standard, machine-readable form. Solace’s product page says the Designer “generates AsyncAPI code from approved models” (Solace). Solace has also been an active contributor to the AsyncAPI project, as a sponsor with staff on its Technical Steering Committee, and the specification includes Solace protocol bindings. The sponsorship tier we cite comes from the original announcement; the current tier is not confirmed.

This page explains what AsyncAPI is for, how Event Portal produces documents, how those documents become code, what a catalogue entry needs to be useful, and the open questions. It belongs to the Event Portal overview in the Solace cluster.

AsyncAPI in two paragraphs

AsyncAPI is to event-driven interfaces what OpenAPI is to REST: a YAML or JSON document that names the channels (topics), the operations (publish or subscribe), the message payloads and the servers. Version 3.0 was released in December 2023 and separated channels from operations, so one channel can be reused by several operations (release notes; specification).

The point is not documentation for its own sake. A machine-readable contract can be validated, diffed between versions, rendered as human-readable docs and used to generate code. Our vendor-neutral AsyncAPI guide covers the specification in depth; this page stays with Solace.

Why Solace AsyncAPI documents matter between IT and OT

Interfaces between plant systems and enterprise systems are where integration projects lose time. The MES team, the ERP team and the controls team each describe the same event in their own words, and the first integration test is where the differences surface.

A shared contract moves that argument earlier. If the event that tells ERP a batch is complete is described once, with its topic, payload, units and delivery mode, every team builds against the same document. A change to the payload becomes a new version that consumers can see coming, rather than a broken parser on a Monday morning.

It also makes the interface reviewable. A security or network team reviewing a new plant-to-cloud flow can read an AsyncAPI document and see exactly which topics cross the boundary and in which direction. That is a better input to a firewall rule or a Message VPN design than a slide.

What it does not do. AsyncAPI describes an interface; it does not enforce it. A producer can still publish a payload that violates the document. Enforcement needs a runtime check, usually a schema registry or validation in the consuming application, and that is a separate decision from adopting the format.

How Solace AsyncAPI export works in Event Portal

Event Portal produces AsyncAPI documents at three levels, each for a different audience (Event APIs docs; applications docs).

Source object	What the document describes	Typical reader
Application version	Everything one application publishes and subscribes to	The developer building or changing that application
Event API (basic download)	A curated set of events and operations	Internal teams consuming a shared stream
Event API in an Event API Product (comprehensive download)	The same, plus service plan, server details and operation bindings for the associated brokers	A consumer who needs to connect, not only to understand

All downloads are available in JSON or YAML, and Event Portal-specific extensions can be excluded from the generated document, which matters if a tool downstream rejects unknown fields. Solace’s docs note that Event API Products are a Beta feature as of October 2026.

What the docs do not say. The pages we reviewed do not state which AsyncAPI specification version Event Portal exports. Older Solace material refers to AsyncAPI 2.x exports; whether current exports are 3.0 is something to confirm before writing a pipeline that parses them.

From AsyncAPI document to running code

Code generation. The AsyncAPI project maintains generator templates that turn a document into application skeletons and HTML documentation. In practice, generated code is a starting point: it gets the topic strings, payload classes and connection boilerplate right, and a developer writes the business logic.

The return path. Once applications run, the Event Management Agent can discover topics, queues and subscriptions on the brokers so Event Portal can audit them against the design. That is the step most AsyncAPI-in-Git approaches lack.

What a useful catalogue entry contains

The Catalog is Solace’s “storefront” for applications, events and schemas. Whatever tool holds it, an entry that a plant engineer and an IT developer can both act on needs the following:

• A topic that follows the agreed hierarchy, with variable levels named, for example site, area, line and cell. See Solace topics and wildcards.
• A schema with units and meaning, not only types. “Temperature, number” is not enough; “°C, filler bowl, 1-second average” is.
• An owner and a producing application, so a question has someone to go to.
• Delivery expectations: direct or guaranteed, expected rate, and whether consumers should use a queue. The trade-offs are on Solace guaranteed messaging.
• A version and a lifecycle state, so consumers know whether they are building on something stable.

An illustrative scenario: an analytics team wants downtime events from three packaging lines. With a catalogue, they find the line/downtime event, read that it is guaranteed, owned by the MES team and at version 2.1, download the AsyncAPI document and request access. Without one, the same answer takes a week of emails.

Getting existing interfaces into the catalogue

The docs we reviewed describe exporting AsyncAPI, not importing it. Three routes exist in practice:

1. Discovery. Scan running brokers with the Event Management Agent and import what it finds. This captures what is real, including what nobody documented.
2. Community importer. An AsyncAPI importer for Event Portal has been published as an npm package by Solace community contributors. It is not presented as a supported product.
3. The Event Portal MCP server. Solace has described using it with AI coding assistants to analyse code and import applications, events and schemas into Event Portal.

Where it gets hard

• Version uncertainty. Until Solace states which AsyncAPI version it exports, treat downstream parsers as a risk.
• Two sources of truth. If teams also keep AsyncAPI files in Git, decide which one wins and automate the sync, or they will diverge.
• Schema governance is a separate product. Event Portal records schemas at design time; enforcing them at runtime needs a registry such as the Solace Schema Registry.
• Beta products. Event API Products, the level that carries server details and bindings for external consumers, are Beta as of October 2026. Do not promise a supplier a data product contract built on a Beta feature without a fallback.
• Catalogue upkeep is a job. Someone has to review new entries, retire old versions and chase owners when an event has none. Without a named owner and a monthly review, the catalogue goes stale at the same rate as the spreadsheet it replaced.
• Bindings tie the document to Solace. A comprehensive document with Solace bindings is less portable to another broker. Keep the basic version for vendor-neutral sharing.

---

Related: Solace Event Portal · Solace Event Management Agent · AsyncAPI guide · Solace hub