Hello! I have the following curl request (confirmed working) curl --request POST \ --url https://example.net \ --header 'Authorization: Bearer asupersecrettokentoauthenticatewith' \ --header 'Content-Type: multipart/form-data…

[image] pramsky: I reached out to the vendor and he suggested it may be the boundary that is causing the issue. The boundary from HTTPoison meets the requirements of RFC2046 - it’s more than 1 and less than 70 characters from the specified character set. If the vendor’s parser is breaking on …

what’s the error you are getting @pramsky ?

The vendor endpoint returns an error 400. To debug, I did the 2 posts to pipedream and see there is a difference in the content type used for the form fields. The curl request [01 - curl request] Httpoison request [02 - elixir httpoison request]

[image] pramsky: I did the 2 posts to pipedream Can you extract the actual contents of the two requests?

Here are the responses when sent to httpbin.org/anything . Converted to elixir map. This is the json response from the curl request %{ "args" => %{}, "data" => "", "files" => %{"file" => "<<BASEENCODED IMAGE FILE>>"}, "form" => %{ "from" => "5555555555", "orgid" => "1234567890987654…

I don’t think comparing what comes out of HTTPBin’s parser is sufficient to see the issue - I only see two differences: the boundary string in the Content-Type; that’s intentionally random and so not relevant the Accept header from Curl is not present in the other It’s worth a try to add that hea…

I was able to get the post text fields to show up in pipe dream as text by adding [“Content-Type”: “text/plain”] to the payload tuple. It still does not work on the vendor site. I reached out to the vendor and he suggested it may be the boundary that is causing the issue. I have the logs of the POS…

Thanks for the response @al2o3cr I believe you may be right about the content-length. I setup a local server to capture raw post dumps and could not really see why the httpoison request would fail while the insomnia request works fine as both requests looked correct. Testing it with pipedream showe…