In phase one of the catalyst, we successfully demonstrated the use of the AsyncAPI standards for event driven architectures as an alternative to the existing OpenAPI REST based definition. The TMF have now adopted AsyncAPI and a version of TMF 925 Async Trouble ticket is available on their site in the pre-production table. In this second phase of the catalyst we want to build on the work to create a real-world scenario using the ODA Canvas to show a use case that can use both AsyncAPI and OpenAPI as service providers will not be building all new systems and most likely evolve towards an event driven architecture and leverage their existing components as that happens. We will use a gateway that acts as an event bridge that provides an implementation of the TMF 688 event management API that allows components to create and register for topics over which event notifications can be sent. The topics can be sent either over OpenAPI REST call backs or to Kafka topics using AsyncAPI. The gateway will allow a company’s partners to use OpenAPI REST calls but does not require them to adopt new technologies, while allowing a company to transform its stack using a mix of existing components and new components built on Kafka or other such technologies. The component will be made available to members in the ODA Canvas as part of the catalyst, but the Oryx gateway requires a licence to use. We will submit a document that is a set of guidelines and recommendations on how to implement Async API using the TMF Event Management API which we hope will become an official TMF document.