Camunda 8 connector manual: call a REST API securely
Configure an outbound REST connector, map responses and test safe failure handling.
Prepared on 20 Oct 2026 for editorial review. Product specifications and company research results are not asserted unless verified.
1. Choose a sandbox API and connector
Use an API you are authorised to test and a non-production Camunda environment. Add an outbound REST connector task using the available connector template. Confirm the connector runtime and template versions are compatible with your installation.
2. Configure the request
Set the endpoint, HTTP method and required headers. Use a sandbox GET request first to avoid side effects. For a POST workflow, define the JSON payload explicitly and validate required variables before the connector executes.
Select the authentication method documented for that connector. Reference credentials through the deployment’s supported secret mechanism rather than placing them directly in BPMN properties, variables or screenshots. Restrict outbound destinations and network access.
Separate human login, the connector runtime’s machine access to Camunda and the connector’s credentials for the destination API. They are different trust boundaries. In SaaS, deploy to the cluster containing the required secrets. In Self-Managed, configure the runtime’s documented secret provider and machine authentication; a secret created in an unrelated environment will not resolve automatically.
Secret syntax is release-sensitive: legacy connector references such as {{secrets.API_TOKEN}} and newer camunda.secrets references have different resolution mechanisms and availability. Consult the migration guide for the installed release rather than performing a blind string replacement. Test rotation and a missing-secret failure in the sandbox.
3. Map the response
Store only the fields the following task needs. Configure result variables or expressions according to the connector documentation and check the expression syntax against the installed template. Handle absent fields and unexpected response types explicitly.
4. Deploy and observe
Deploy the model, start a test instance and inspect the connector result in Operate. Compare the mapped response with the authorised API’s recorded request or sandbox logs, taking care not to expose tokens or sensitive data.
5. Exercise failure paths
Test authentication failure, non-success HTTP responses, timeout and unavailable service. Distinguish a business error from an operational incident using the mechanisms supported by your version.
Only retry side-effecting calls when the remote operation is idempotent or protected by an agreed idempotency key. Document reconciliation for uncertain outcomes; a timeout does not prove that the remote service performed no action.