How to use the rest api of the zeebe engine

Hello, I am trying to use the rest api of the zeebe client in version (8.5.0 alpha 2 and 8.5.0) download the documentation collection GitHub - camunda/zeebe at 8.5.0-alpha2 /zeebe/gateway-protocol/src/main/proto/rest-api.yaml, my intention is to be able to complete the user task, but I have not been able to highlight the request since when making it to position 8080 or 8085 it gives the following answers.
8080 Error: connect ECONNREFUSED localhost:8080
8085
{
“timestamp”: “2024-04-07T01:08:35.353+00:00”,
“status”: 404,
“error”: “Not Found”,
“path”: “/api/v1/topology”
}
I would like some guidance on how to use the rest api of the zeebe engine
Here I leave an image of how I have my solution installed in Docker

Hi @Roger !

This can have multiple reasons, one is running different versions of Zeebe and the other components.

Tomorrow we will release the 8.5.0 minor version, and I recommend to just update all components to it (you can use the fresh new docker-compose then and adjust it) and try it again.

Best,
Christian

1 Like

I think this link can help you: Uncomplicating communication via API in Camunda 8 Self-managed using Postman or Insomnia | by Domingos Dias | Mar, 2024 | Medium

Hello, thank you, I reviewed the post but I am looking to connect to the api directly from the Zeebe engine without using tasklist and operate.

This article shows how you can connect to Zeebe

ok, thank you very much, I will update my docker compose since what I am looking for is to connect directly to the zeebe rest api without using tasklist and operate and that is only available in version 8.5

Yes, I have already connected using the gRPC method, but in version 8.5.0 of Camunda, apart from the gRPC connection, they launched a rest api to the zeebe engine, which is what I want to connect to.

@Roger, are you connecting to the cluster (and the Zeebe REST API) using the Zeebe client or plain HTTP requests (using Postman or anything else)?

The request you initially posted is trying to fetch data using the /api/v1/topology path which was an intermediate path we used in an alpha (I think alpha2). With the final version, as you can see in the documentation you linked, it sits at /v1/topology.