Is your feature request related to a problem? Please describe.
The Camunda Operate Outbound connector (io.camunda.connectors.CamundaOperate.v1) was deprecated when the Operate API was retired in favour of the unified Orchestration Cluster REST API (v2). There is currently no first-party element template that provides the same read-only data-fetching experience against the new API. Process modellers who relied on the Operate connector to search and fetch process instances, incidents, variables, decision data, user tasks, and audit data have no drop-in replacement and are forced to hand-build raw REST connector calls with full URL/auth/body configuration on every service task.
Customer request from Aztec and BP3.
Describe the solution you'd like
A new first-party element template Camunda Orchestration Cluster API Connector that wraps the standard io.camunda:http-json:1 REST Connector job worker and exposes the v2 API with the same UX as the old Operate connector:
Single Endpoint dropdown covering every read-only v2 entity available on 8.9: process-instances, process-definitions, element-instances, incidents, variables, user-tasks, jobs, decision-instances, decision-definitions, decision-requirements, batch-operations, batch-operation-items, message-subscriptions, correlated-message-subscriptions, audit-logs, authorizations, groups, roles, tenants, mapping-rules
Operation dropdown: Search (POST /{entity}/search) and Get by key (GET /{entity}/{key})
SaaS + Self-Managed deployment modes with OAuth 2.0 client-credentials flow pre-wired (audience zeebe.camunda.io for SaaS, user-supplied for SM)
v2 pagination shape ({filter, sort, page:{limit | after | before | from}}) per the search-models OpenAPI spec
Modern tooltip-only properties-panel UX (per bpmn-io/internal-docs#1322 and camunda/example-data-properties-provider#18) no inline descriptions, all helper text behind the ? icon
Sensible defaults: limit: 100, connection timeout 20s, result variable + result expression stubs
Read-only by design: GET (by key) and POST /search only; no state-changing operations
engines.camunda: ^8.9
Marketplace listing as the canonical replacement for the deprecated io.camunda.connectors.CamundaOperate.v1
Describe alternatives you've considered
Stay on the deprecated Operate connector rejected: Operate API is retired, connector marked deprecated, no path forward.
Hand-rolled REST Connector instances per task rejected: every service task requires copy-pasting OAuth config, audience, URL construction, pagination body shape. High error rate, brittle when the API evolves. This is the current workaround Aztec and BP3 are using.
Generic "Orchestration API Endpoint" template that exposes a single apiEndpoint String field rejected: forces modellers to know v2 path syntax by heart and rebuild filter/sort/pagination payloads from scratch. Loses the entity-aware UX that made the Operate connector approachable for non-developers.
Additional context
Requesting customers: Aztec, BP3.
Is your feature request related to a problem? Please describe.
The Camunda Operate Outbound connector (io.camunda.connectors.CamundaOperate.v1) was deprecated when the Operate API was retired in favour of the unified Orchestration Cluster REST API (v2). There is currently no first-party element template that provides the same read-only data-fetching experience against the new API. Process modellers who relied on the Operate connector to search and fetch process instances, incidents, variables, decision data, user tasks, and audit data have no drop-in replacement and are forced to hand-build raw REST connector calls with full URL/auth/body configuration on every service task.
Customer request from Aztec and BP3.
Describe the solution you'd like
A new first-party element template Camunda Orchestration Cluster API Connector that wraps the standard io.camunda:http-json:1 REST Connector job worker and exposes the v2 API with the same UX as the old Operate connector:
Single Endpoint dropdown covering every read-only v2 entity available on 8.9: process-instances, process-definitions, element-instances, incidents, variables, user-tasks, jobs, decision-instances, decision-definitions, decision-requirements, batch-operations, batch-operation-items, message-subscriptions, correlated-message-subscriptions, audit-logs, authorizations, groups, roles, tenants, mapping-rules
Operation dropdown: Search (POST /{entity}/search) and Get by key (GET /{entity}/{key})
SaaS + Self-Managed deployment modes with OAuth 2.0 client-credentials flow pre-wired (audience zeebe.camunda.io for SaaS, user-supplied for SM)
v2 pagination shape ({filter, sort, page:{limit | after | before | from}}) per the search-models OpenAPI spec
Modern tooltip-only properties-panel UX (per bpmn-io/internal-docs#1322 and camunda/example-data-properties-provider#18) no inline descriptions, all helper text behind the ? icon
Sensible defaults: limit: 100, connection timeout 20s, result variable + result expression stubs
Read-only by design: GET (by key) and POST /search only; no state-changing operations
engines.camunda: ^8.9
Marketplace listing as the canonical replacement for the deprecated io.camunda.connectors.CamundaOperate.v1
Describe alternatives you've considered
Stay on the deprecated Operate connector rejected: Operate API is retired, connector marked deprecated, no path forward.
Hand-rolled REST Connector instances per task rejected: every service task requires copy-pasting OAuth config, audience, URL construction, pagination body shape. High error rate, brittle when the API evolves. This is the current workaround Aztec and BP3 are using.
Generic "Orchestration API Endpoint" template that exposes a single apiEndpoint String field rejected: forces modellers to know v2 path syntax by heart and rebuild filter/sort/pagination payloads from scratch. Loses the entity-aware UX that made the Operate connector approachable for non-developers.
Additional context
Requesting customers: Aztec, BP3.