What are you looking for?

A Deep-Dive into the Architecture of Connectors

Check out this deep-dive into the architecture of Camunda Connectors. Learn about custom Connectors, Connector reusability, and more.
  • Blog
  • >
  • A Deep-Dive into the Architecture of Connectors

At the 2023 Camunda Community Summit, Senior Product Manager Bastian Körber and Software Engineer Pavel Kotelevsky shared a deep-dive into the architecture of Camunda Connectors. If you’re a software developer who’s thinking about building a custom Connector, or a low-code developer or business technologist who’s curious about Connector reusability, this is a great place to start.

Bi-directional connectivity through outbound and inbound Connectors

When we started designing Connectors, we knew that bi-directional connectivity was important to ensure that both IT teams and business stakeholders would have as much flexibility as possible when orchestrating business processes across all types of different endpoints. That’s why Connectors come in two flavors: outbound and inbound.

Outbound Connectors enable Camunda-based processes to trigger things to happen in external systems or services. We already have a sizable library of built-in outbound Connectors for products like Slack and Google Drive and for technologies like Kafka and AWS Lambda. Our community and partners have also been releasing open source outbound Connectors, which you can find in the Camunda Community Hub’s Connectors Awesome List.

Inbound Connectors enable processes in Camunda Platform to receive data or messages from external systems or services. We started by launching support for inbound Connectors on BPMN Start Events, and we’re adding support for inbound Connectors on Intermediate Events soon.

There are three types of inbound Connectors:

  • Inbound webhook Connectors allow a process to be triggered by any system that supports webhooks or that can send an HTTP POST payload to a URL.
  • Inbound subscription Connectors trigger a process by subscribing to a message queue topic. The process can receive messages from an external system or service (such as Kafka or RabbitMQ) using message queueing technology.
  • Inbound polling Connectors trigger a process by polling an external system or service for new data if it fits a defined condition.

We currently offer webhook Connectors for HTTP and GitHub; to learn how to use these, check out Start a Camunda 8 Process via REST with Webhooks and How to call the Camunda Inbound Webhook from Postman. More webhook Connectors, and new subscription and polling Connectors, will be released very soon.

A multilayer coding experience for everyone

Bi-directional connectivity isn’t the only important design consideration for Connectors; the coding experience is important, too. We want to be sure that we empower users with different skill sets to build and use Connectors. That’s why we offer a multilayer coding experience.

Camunda Connectors Architecture with 4 levels: Connector SDK, Protocol Connector, Configurable Connector Templates, and Out-of-the-box Connector

Connector SDK

Let’s start with the bottom layer: the Connector SDK enables you to build custom Connectors from scratch. You can use the SDK to address unique integration challenges that aren’t met by other types of Connectors; for example, integrating with a proprietary piece of software. The SDK provides complete control over the Connector implementation for both outbound and inbound connections. It enables you to build environment-agnostic runtime behavior for Connectors, so you can reuse the Connector’s logic in different setups without modifying the code.


A team of Java developers can build a custom Connector that incorporates complex business logic for data processing, analysis, or automation, enabling seamless integration with other systems.

Protocol Connectors

Protocol Connectors implement popular integration protocols such as HTTP REST, SOAP, and GraphQL for both inbound and outbound connections. Protocol Connectors provide an amount of built-in functionality compared to the Connector SDK; but at the same time, they’re designed to be highly generic, ensuring reusability. If you need to create a custom Connector and you know it will require a common protocol such as REST, then you can build on top of the REST Connector and save a lot of development effort. To get started with protocol Connectors, visit the documentation.


A team of low-code developers can build a custom Connector for a specialized product such as Duck Creek on top of Camunda’s REST Connector, enabling integration through Duck Creek’s APIs.

Configurable Connector templates

Configurable Connector templates allow you to define a Connector template in JSON. Templates allow you to maintain a consistent and familiar user experience across different types of connections. Connector templates offer a balance between ease of use and customization. You can quickly customize a Connector for various integration scenarios, without having to start from scratch using the Connector SDK. You can also reduce the cost of maintaining Connectors by reusing protocol Connector code.


A people operations team can quickly create an integration between the company’s HR system and its payroll system by building domain-specific Connector templates for the systems and reusing a protocol Connector for communication (such as the REST Connector). This approach greatly reduces the development resources that are required.

Out-of-the-box Connectors

Everyone using Camunda Platform 8 can add out-of-the-box Connectors to their BPMN process models. These Connectors simplify integration with external systems, reducing the need for coding expertise and lowering the barrier to entry for less technical users. You don’t have to worry about configuration details such as API endpoints, authentication, HTTP methods, and headers; that’s all built into the Connector itself.

We regularly release new out-of-the-box Connectors to Camunda 8 SaaS. Camunda 8 Self-Managed customers can find Connector bundles on GitHub. To learn how to install Connectors in your Self-Managed setup, visit the documentation.


A consumer lending team can design a process that uses the:

  • REST Connector to get a loan applicant’s credit score from a credit bureau’s API
  • Slack or Microsoft Teams Connector to notify a supervisor when an application requires special review
  • Automation Anywhere or UiPath Connector to trigger an RPA bot that enters data into a legacy banking system
  • SendGrid Connector to automatically send an email to the applicant
  • … and so on

When should I use a Connector versus a Zeebe job worker?

A question we sometimes hear from people who are experienced with Zeebe, our cloud-native workflow engine, is when to use a Connector versus a  Zeebe job worker. The answer really comes down to reusability.

Connectors are entirely focused on business logic and are runtime-agnostic by their nature. You should implement a Connector when you have tasks that you want to run in different environments without changing code. The Connector SDK is somewhat limited compared to job workers; for example, you can’t access low-level Zeebe APIs or precisely control how Connectors map to Java threads, like you can with job workers. However, Connectors are designed to be easier to implement.

If you have questions about using Connectors and job workers, visit our forum to chat with other users and the Camunda team.

Learn more

To learn more, check out A Deep Dive into the Camunda Connectors Architecture, presented by Senior Product Manager Bastian Körber and Software Engineer Pavel Kotelevsky at the 2023 Camunda Community Summit.

Try All Features of Camunda

Related Content

Build software that meets needs while still protecting the environment for future generations.
Learn about the best programming languages for microservices, plus how to compose and orchestrate microservices for your project.
Want to go to CamundaCon? Here's how to convince your boss you should be in New York this October.