HTTP Webhook Connector URL


I have Camunda Platform 8 Self-Managed running via Docker Compose. I’m trying to set up an HTTP Webhook inbound connector to start a process instance in Camunda externally.

Documentation (HTTP Webhook | Camunda Platform 8 Docs) specifies this step:
“In the Webhook Configuration section, set the Webhook ID. This value is used to build a URL endpoint of your webhook. For example, given the Webhook ID value is myWebhookPath, the complete webhook URL endpoint will be http(s)://<base URL>/inbound/myWebhookPath.”
I deployed a model using a webhook template but having problems with the REST endpoint.

What should the point to? In docker-compose.yaml connectors container is configured to listen on port 8085 so I tried http://localhost:8085/inbound/myWebhookPath but it won’t accept any POST requests.

Thank you.

1 Like

It depends on the container networking.

Just to check, you set the value in the configuration as myWebhookPath, right? Not the entire URL…


Correct. Just ‘myWebhookPath’:

I’m using docker-compose.yaml from here: camunda-platform/docker-compose.yaml at main · camunda/camunda-platform · GitHub. I did change the value of CAMUNDA_CONNECTOR_WEBHOOK_ENABLED to “true” in the file.

Couldn’t find that setting (anymore?) in the yaml file and assume it’s because of a change in the configuration of inbound webhook handling.
So if I understand the self-managed inbound Webhook docs right, the caller should reach the connectors framework.
So baseURL is typically localhost:8085 am I right?

Just rechecked the current documentation and still ask myself how this looks in selfmanaged scenarios and come here again…
Webhook Documentation says base url - is that typically localhost:8085 in the docker case per default?

Good day, @asys3!

I have an impression that you’re confused with the documentation related to inbound connectors. I am here to help and happy to get your feedback regarding how we can improve.

If I understood your question correctly, yes, the base URL is typically localhost:8085 for camunda-platform Docker setup.

Just for further reference, to start a web-hook on SM, one would need to do the following:

  • Start camunda-platform bundle, e.g. docker-compose -f docker-compose-core.yaml up
  • Deploy a diagram containing web-hook as one on screenshot
  • curl a web-hook as per example below

# input
curl -X POST -H "Content-Type: application/json" -d '{"myId": 123456, "myMessage": "Hello, world!"}' http://localhost:8085/inbound/helloDemo
# output

Please do let me know if you have any further question!

1 Like

Is there a way to retrieve the object of “executedConnectors” with the processInstanceKey and any additional information in the current version?

Hi @some_developer, the implementation has changed (talking about 8.2.x) in the meanwhile and a single webhook invocation is bound to a single Connector execution. A single webhook id can only be used by one webhook inbound connector. Using the same webhook id twice will lead to an error.

Does that help you?

Not exactly, I want to retrieve the values of ‘processInstanceKey’ and ‘processDefinitionKey’

You can access the process definition related properties via the InboundConnectorContext by calling the InboundConnectorDefinition getDefinition(); method. The context is available in the activate lifecycle method. You could store it in an instance and return it as a result. The processInstanceKey is not available in the WebhookConnectorExecutable as of now.

And what about the special keyword “=correlation” mentioned in this manual? How can I use it to retrieve that object in the webhook response?

The correlation key expression is used to extract the correlation key from the request data. It will be passed to the zeebe engine to correlate the message (request) to your process instance.

And when the manual states that if I enter “=correlation” in the Response Body Expression field, it will return a JSON with processInstanceKey and other values that I desire. I have tried this, but with no success.

It stopped working in 0.24.0-alpha2; however, it still works in 0.23.2 and 0.24.0-alpha1.