Deployment Rest Api - multiple file with OpenApi

Hi everyone,

I’m having some trouble regarding the deployment/create endpoint to deploy multiple files using server-side auto generated code from the openApi documentation.

I’ve downloaded Camunda’s openApi json, converted to yaml and used it to generate code with openApi generator. However, the code generated is not compatible with the deployment implementation in the client side (Camunda). It simply puts a List of Files in a single Part which won’t work in Camunda.

I’d like to have the right openApi configuration to make openApi generator able to generate code that will be able deploy multiple files to Camunda.

I hope anyone is able to help me. Thank you in advance.

Hi @tiagorego21,

Could you please share details on the performed steps:

  • Which Camunda version do you use (OpenAPI json and engine)?
  • Which OpenAPI generator do you use and what is the details that you provide - language and additional configuration?

Best regards,

Hello Yana,

thank you for the reply. Regarding your questions:

  1. I’m using the 7.14 version of the Engine and retrieved the json file from here for the 7.14 version.
  2. I’m using the openapi-generator-cli-5.0.1 which I got from here.

I’ve already tried some configurations in Yaml for the file part of the request body which didn’t solve the problem, for instance:

  type: string
  format: binary
  nullable: true


  type: array
    type: string
    format: binary

Does it answer all your questions? Thank you once again


I run in to the same problem.


OpenAPI Version 7.14.0
OpenApi Generator 4.7.3

I generate a python client:

wget -O openapi-generator-cli.jar
java -jar openapi-generator-cli.jar generate -i ./resources/openapi/7.14/openapi.json -g python -o camunda


What happens is, when using the deployment/create endpoint, all files attached to the data attribute get the name data, which means I am sending each file as a duplicate making the last file the only winner left in camunda run.

Its like sending files with curl all having same key: -F data=my_model.bpmn -F data=task-form.html. The last one wins (task-form).

The problem seems to be the MultiFormDeploymentDto specification in openapi.json with the snippet posted by @tiagorego21 :

          "data": {
            "type": "string",
            "format": "binary",
            "nullable": true,
            "description": "The binary data to create the deployment resource.\nIt is possible to have more than one form part with different form part names for the binary data to create a deployment."

Question is: Can we describe data in such a way, that it does not generate files with duplicate names? Maybe making it a map of binaries?

I don’t know enough about openapi, yet, to answer that.

Thank you,

Hello @tiagorego21 and @Noordsestern,

Thanks for the details, I didn’t have a chance to look into the issue yet.
However I think Markus might be on the right track, hopefully I will get back to you in the following days with my findings.

Best regards,

1 Like

@tiagorego21 what is the command that you run to generate the client? Do you generate python client as well?

Hello @Yana,

I used the same command but generated a java client instead. Here is the command:

java -jar openapi-generator-cli.jar generate -i openapi.yaml -g java -o temp/

Thank you.


I was able to confirm the reported issue and created a bug report for it - CAM-13105.

However, I am not sure we can easily fix it in the OpenAPI documentation. Ideally we need to define an array of binary properties with undefined names. I am not certain if this is possible with the current specification or at least not exactly as we need it.
I tried the additionalProperties property but that definitely doesn’t work for OpenApi Generator (results in [ERROR] Map of form parameters not supported. Please report the issue to if you need help.). There was better result in the generated client with swagger codegent client generator, but I didn’t test it thoroughly though as I am not convinced that it’s allowed to make such definition and it’s still not 100% correct. Example for reference:

          "data": {
            "type": "object",
            "additionalProperties": {
              "type": "string",
              "format": "binary"

As next steps, I will discuss the issue internally with the team and most probably create an issue in the OpenAPI spec to ask for guidance.

Unfortunately the only workaround that I could suggest so far is to modify the generated client code to correctly resolve the deployment resources.

Best regards,


What happened with the jira issue? Jira is buggy throwing all the time to the login screen

Gas this been fixed in 7.15?

1 Like

Try to access it again, it is still there. If that’s not the case for you please let me know to check further.

yes, it is. jira does not seem to work on my mobile. But on desktop, it works.