You are viewing limited content. For full access, please sign in.

Question

Question

How do you convert the following curl commands to an HTTP Request Rule in Cloud?

asked on April 29

I am given the following commands for curl from the documentation for an API but for Laserfiche we need HTTP so I asked ChatGPT to convert it and I am not having any luck because the response is thinking that the media_type is text/plain instead of image/png and the resulting uploaded file gets corrupted.

curl --location -g --request POST 'https://api.freshbooks.com/uploads/account/<accountId>/attachments' \
--header 'Authorization: Bearer ' \
--form 'content=@"/path/to/file"'

Here is my conversion from ChatGPT for a POST method with multipart/form-data content type and Yaegaki boundary

--Yaegaki
Content-Disposition: form-data; name="content"; filename="%(Name: entryName; Type: Text).png"
Content-Type: image/png
%(Name: File; Type: File)
--Yaegaki--

Based on the documentation the response should return

"media_type": "image/png", 

Instead it says

"media_type": "text/plain", 

It accepts the file but as the wrong format and all the png information gets corrupted. The problem must be in my conversion from curl commands to HTTP. I tried with binary encoding but there is not binary command in the curl command and the server rejects it.

0 0

Replies

replied on April 29

This may be an issue because that API is expecting binary data but you're sending base64 (I think).

Note: The default file content encoding is base64 string. To upload the file under binary encoding you must add Content-Transfer-Encoding: binary

Reference: Web Request Rule

1 0
replied on April 29

Oh the file type is not a file? It is being converted to a string? I did not realize this. That might be a problem, the curl command required for this endpoint is indicating that a file must be provided. I can only use the binary encoding with certain formats like PDF and TIFF but when I try it just responds with media_type: text/xml instead of the format I requested under Content-Type and it gets corrupted still.

So it seems endpoints that require files can not be called with a web request rule?

0 0
replied on April 29

According to the API documentation, this endpoint returns a JWT token and the path to the uploaded attachment.

0 0
replied on April 29

That is correct, we do not have any problem getting the jwt. It is just that that file uploaded to their site is physically altered and corrupted. The jwt is just used as a reference to attach the uploaded document to a expense when creating one with the next API endpoint call.

0 0
replied on April 29 Show version history

Did you try adding the Content-Transfer-Encoding suggestion from Kevin?  Here's a screenshot of an example from our developer site.  You may want to play around with the possible options for that (binary, base64)...

 

Laserfiche Repository API - Entry - Import - Web Request Rule

0 0
replied on April 29

I have tried the binary encoding, for example with application/pdf or image/tiff but it keeps responding media_type: text/xml and corrupting the images or pdf files.

Based on their documentation, the media_type response should match the file type that I upload which is defined by the Content-Type. I see in your request your not defining a Content-Type. How does it know what your file is?

0 0
replied on April 29

I believe you may have to set Content-Type: application/octet-stream or multipart/form-data. You aren't just sending a file. You're sending 

form-data; name="content"; filename="%(Name: entryName; Type: Text).png"
0 0
replied on April 29

How would I use one or the other? I have to choose Content Type of multipart/form-data in order to be able to enter a boundary. This is in the rule configurator.

The Content-Type defined in the body is different, that defines the file. I can set that to octet-stream but it would be in addition to the multipart/form-data content type selected to allow me to enter a custom boundary.

0 0
replied on April 29
--Yaegaki
Content-Disposition: form-data; name="content"; filename="%(Name: entryName; Type: Text).png"
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary

<file binary content here>
--Yaegaki--

I think you are correct with setting the Content-Type:multipart/form-data where you have it, but you may need to adjust your boundary Content-Type.

0 0
replied on April 29

I tried this as well, it accepts the request but again the resulting file on freshbooks is corrupted.

I also have an email into their API support team, but not sure how many customer they have asking for the HTTP content body. Seems everyone has switched to using curl.

0 0
replied on April 29

Take a look at this post where they are uploading a file to a 3rd party API.  I would recreate their POST info and just replace the relevant values...

 

--aaa
Content-Disposition: form-data; name="%(Name: FileName; Type: Text)"; filename="%(Name: FileName; Type: Text)"
Content-Type: application/pdf
Content-Transfer-Encoding: binary

%(Name: InvoiceFile; Type: File)
--aaa--

 

0 0
replied on April 29

This seems to match my existing rule exactly except with the binary encoding which I have also tried, that keeps turning it into an xml.

--Yaegaki
Content-Disposition: form-data; name="content"; filename="%(Name: entryName; Type: Text).png"
Content-Type: image/png
Content-Transfer-Encoding: binary
%(Name: File; Type: File)
--Yaegaki--
0 0
replied on April 29

Can you be sure to update the "name="content"" part as well?  I recall that being important but I could be wrong.  I would match the example from the other post and just put the same value as the "filename" value.

0 0
replied on April 29

I think the file name only goes under the filename field. I just tested putting the file name into the name field as well and sure enough I get this response from the API server

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.