Hello everyone!
I’m trying to send a message to the Chatwoot API using the HTTP Request node in n8n, but I’m not able to attach two files in the same attachments[] field (repeated field in multipart).
In my workflow, I can download and prepare two binary files (data and data_1).
I would like to send both together, as Chatwoot expects:
-F “attachments=@/tmp/data.jpg”
-F “attachments=@/tmp/data_1.jpg”
However, in the HTTP Request node, when I add two binary parameters with the same name (`attachments[]`), only the last one gets sent. I've tried using `attachments[0]` and `attachments[1]`, but Chatwoot does not accept those.
Is there any way in the HTTP Request node in n8n to send **multiple files in the same field** (that is, repeated fields in form-data)?
Or is there any native workaround, without having to use Execute Command and curl?
I would really appreciate any advice, since to send multiple attachments I can only do it with Execute Command, and I’d like to find a more “pure n8n” solution.
Thank you!
Hi @Vitor_Panini_Rodrigu hope all is well, welcome to the community.
Don’t have access to Chatwoot, so just can hypothesize here. Did you figure out the curl call that works for sending two attachments? If you did, can you share it here?
curl -X POST “https://chatwoot.com/api/v1/accounts/2/conversations/{{ $(‘Edit Fields’).first().json.data.payload[0].id }}/messages”
-H “api_access_token: token_id”
-F “attachments=@/tmp/data.jpg”
-F “attachments=@/tmp/data_1.jpg”
-F “content={{ $(‘mensagem’).first().json.message }}”
-F “message_type=incoming”
I assume you have tried something like this?
Yes, I’ve tried that. It is important to clarify that Chatwoot only accepts file uploads with the field name exactly as attachments. If you use any other name, or send it without the brackets (e.g., attachments), the Chatwoot API will either ignore the files or return an error.
When I try to make this request in n8n using the field name attachments [ ] for both files, n8n either overwrites one of them or simply doesn’t send it. In the end, only one of the two files gets uploaded.
Funny that you mentioned that, I just created a mock server and sent that request to see how the request looks like on the receiving side, and it looks proper:
----------------------------766883644609838927604653
Content-Disposition: form-data; name="content"
CONTENT GOES HERE
----------------------------766883644609838927604653
Content-Disposition: form-data; name="message_type"
incoming
----------------------------766883644609838927604653
Content-Disposition: form-data; name="attachments[]"; filename="favicon-16x16.png"
Content-Type: image/png
�PNG
IHDR(-S5PLTEb�4a�4^�5[�5W�7U�7R�8Q�8/^@.]@-ZA+WA3f>4f?
<...omitted for brevity...>
----------------------------766883644609838927604653
Content-Disposition: form-data; name="attachments[]"; filename="favicon-32x32.png"
Content-Type: image/png
�PNG
IHDR D����PLTE3D5F6F6F.:5F8E7F<E1@3D5F6F5F5E5F4F6F5F3G��
<...omitted for brevity...>
----------------------------766883644609838927604653--
I don’t see any reason for the same request NOT to look the same way when it hits Chatwoot…
And another similar service also provides the same result:
Thank you very much for helping with my question. Could you please check this same request but sending binary files? As you can see in the image, when I try to send two images, the output returns only one attachment.
You can easily test the request by sending it to https://echo.free.beeceptor.com. This resource sends you your own request back, so that you can inspect it. Absolutely free.
I tested sending a request to the endpoint https://echo.free.beeceptor.com, and the response returned only one image. This confirms that there is a limitation in the n8n HTTP Request node, which does not support sending multiple files under the same field name (e.g., attachments). In this case, the second file overwrites the first one. Therefore, the issue is not with the API itself, but with how the HTTP Request node in n8n builds the multipart/form-data payload.
I would like to thank you for your collaboration and support during this analysis. Based on the tests I performed, it’s clear that the limitation is within the n8n HTTP Request node itself and not the API. I really appreciate your help throughout this process!
No problem @Vitor_Panini_Rodrigu, glad to help.
