CreateAssembly fields not utilized in assembly variables unless attached to params.

[christianbradley]

According to your documentation, createAssembly takes two parameters: params and fields.

TransloaditClient.createAssembly(options, cb)

Creates a new assembly on Transloadit, uploading all streams and files that were registered via .addStream() and .addFile() prior to the call to .createAssembly().

You can provide some options:

params - an object containing your template_id, notify_url, some steps that overwrite your Transloadit template and other params to control Transloadit behavior.
fields - an object of form fields to add to the request, to make use of in the assembly via assembly variables.

These fields are sent as multipart/form-data chunks, not as part of params.fields. Note that the REST API documentation does not specify either that it should be sent as part of params.fields, yet I only seem to be able to utilize the assembly variables ${fields.my_field_name} properties within my templates when I send them as params.fields.

This is quite confusing, and should be addressed both in the API and SDK documentation.

[tim-kos]

Hey christian,

It does not matter whether the fields are sent as form-urlencoded fields or as part of the parameters - both ways work. I will update the documentation to make things clearer. Will also check why providing them as opts.fields does not work.

[tim-kos]

I have created a template containing this:

{
  "steps": {
    "import": {
      "robot": "/http/import",
      "url": "${fields.url}"
    }
  }
}

And then I have set up two test scripts, one where the fields are part of the params, and one where they are both on the same level:

https://gist.github.com/tim-kos/f23dd0541e7ffeb80f82c021d9838c30
https://gist.github.com/tim-kos/bc29520c6e27e218bb3889c42e6670af

Both times things have worked fine. :/

Do you have a code example where it did not work for you so that I can reproduce it?

[christianbradley]

Please see the assemblies I sent via transloadit support chat. Note that today, the same code seems to work, so it may be an intermittent issue or an issue with one of the instances, or fixed with an internal release.

[tim-kos]

Alright, will check them out. Will close this for the time being.