Use our declarative API, new description language, or low code UI to connect data and services into event-driven applications
Sources and targets are the start and the end of what we call "Bridges". The data and events flowing through the Bridge are defined using an API object and may undergo filtering, splitting, and/or transformations.
Our open source API helps you combine on-premises systems and cloud services in an automated manner
TriggerMesh accelerates the move to an event-driven architecture
Triggermesh runs on Knative, so it is an easy platform to deploy and operate. You can incorporate existing Kubernetes objects like Secrets and Configmaps when defining your integrations.
Logs and metrics can also be consumed with any Kubernetes-ready observability platform
Our integration components are API objects that can be managed declaratively from the command line, CI/CD pipeline or integrated in code. Less technical users benefit from the low-code TriggerMesh UI
With Triggermesh, you get a full Event Driven platform powered by Knative. Our integrations inherit a strong sense of loose coupling, allowing for unlimited extensibility
Enterprises can use our platform out of the box to build applications that rely on Event-Driven Architectures and serverless.
TriggerMesh application flows are bundled into Bridges – sets of Kubernetes objects that are deployed and tracked as a unit
Bridges provide information about the status of their components through a single API call
Kustomize, Helm, or other Kubernetes deployers can be used to generate Bridge objects
Use this Bridge to perform sentiment analysis on newly-created Zendesk Tickets.
This Bridge consumes messages from an AWS SQS queue and sends the content by email with SendGrid.
Send messages from a Slack bot to a Google Sheet.
Send Salesforce events to be indexed in Elasticsearch.
Send Oracle Cloud metrics to Datadog.
Send SMS notifications via Twilio on GitHub push events.
This Bridge consumes Azure Activity Logs generated within an Azure Subscription and sends them as CloudEvents to Splunk, where they can be further analyzed and visualized.
Listen to Slack events and forward them to a Confluent Kafka cluster for further processing.
This Bridge forwards GitLab events from a specific repository to be indexed by Elasticsearch.
This Bridge listens to GitHub events from a specific repository and forwards these events to AWS EventBridge.
This Bridge configures a GitHub event source and sends all received events to a service called event-display.
This Bridge configures a GitLab event source to receive events from GitLab when a particular event happens in a repository, then the event is used to trigger the execution of a function in AWS Lambda.