I'm having some trouble while trying to send a PDF file to Microsoft's Form Recognizer service.
Instead of sending the PDF Url location, I need to send the PDF file. On my experience, sending files could be done using base64 but it seems that Microsoft service is not compatible with base64 format. Whenever I try sending the file the server responses:
{
"error": {
"code": "1000",
"message": "Invalid input file."
}
}
I need to know how I should convert my PDF to the required application/pdf "Binary PDF data". I can't find any documentation referring to this conversion.
The Form Recognizer API webpage is: https://brazilsouth.dev.cognitive.microsoft.com/docs/services/form-recognizer-api-v2-1-preview-3/operations/AnalyzeWithCustomForm
And here you can find the complete documentation webpage: https://learn.microsoft.com/en-us/azure/cognitive-services/form-recognizer/quickstarts/client-library?tabs=preview%2Cv2-1&pivots=programming-language-rest-api
Thanks!
You are correct that base64-encoded requests are not supported.
If you are using curl and you want to send a local file, run this:
curl -i https://{endpoint}/formrecognizer/v2.1-preview.3/custom/models/{modelId}/analyze -H 'Content-Type: application/pdf' \
-H 'Ocp-Apim-Subscription-Key: {subscription key}' --data-binary #/path/to/your/file.pdf
The key parts are the Content-Type header, which must match a supported value, and the --data-binary flag, which is the path to a local PDF file. Be sure to include the -i flag so that you can see the Operation-Location header in the response, which is where you can retrieve the analyze results.
You may also want to take a look at the Form Recognizer SDKs for C#, Java, JavaScript, and Python.
Related
My main objective is to upload .pptx/.docx/.pdf file to Microsoft Sharepoint using Microsoft Graph API.
Am able to upload to simple text files using the below "PUT" request, where the content-type is multipart/form-data
https://graph.microsoft.com/v1.0/drives/{drive-id}/root:/{simple.txt}:/content
But for .pptx/.docx/.pdf files, although am getting response as "200 ok", but no file is getting creating in sharepoint site document.
I have correctly configured File type with "File" as the key and selected the appropriate file in the value of the body of the request in postman.
Observation -> While uploading txt file, the response is "201 created" and the contents of the uploaded files is getting changed. For example, if the content was "Hello there". The upload file content is,
----------------------------404518839734975569926100
Content-Disposition: form-data; name="File"; filename="sample.txt"
Content-Type: text/plain
Hello there
----------------------------404518839734975569926100--
Can someone explain what's going on here and how to upload pptx/doc/pdf file in sharepoint using MS Graph API's.
You could upload the .docx file using Graph API in post man like this.
PUT drives/{drive-id}/root:/fileName.docx:/content
In Body, choose binary type.
This has me baffled.
I can request the document content as base64 with curl , no problem.
curl https://demo.docusign.net/restapi/v2/accounts/<id>/envelopes/<id>/documents<id> -H"Authorization : Bearer <token>" -H "Content-Transfer-Encoding: base64" -o <filename>
Return headers are
Content-Disposition: file; filename="blah"; documentid="1"
Content-Transfer-Encoding: base64
and the file is returned in base64 format.
Using the Apache oltu oauth2 library which underneath uses HttpURLConnection I cannot get the response to be sent in base 64. I have the request headers set to
Content-Transfer-Encoding: base64
Accept : */*
Authorisation : Bearer <token>
But all I ever get back is the binary version of the file which ultimately bombs out because the library saves the stream as a string which screws up the pdf.
I can't trace the return header , but the request header definitely has the above fields set.
Is there anything in the Docusign endpoints which look at the User-Agent or anything else to determine whether to do the base 64 encoding ? Why else would it only ever return the binary stream ?
I suspect your Java output is not the same and the best way to confirm this is to capture exact JSON/SOAP request posted by your API calls via Java to DocuSign by following steps explained at this DocuSign support article https://support.docusign.com/guides/ndse-user-guide-api-request-logging
Please post these and I am sure it will be we will be able to deduce the library "add" that is changing the actual output.
OK thanks #david for the advice on logging the requests in docusign. I find that the "Transfer-Content-Encoding" header has mysteriously disappeared on arrival at the Docusign server. Some digging indicates that
a. this header is dodgy anyway for non-email uses and that
b. in the Java HttpUrlConnection class it is "removed" as security measure. You can apparently set some flags to revert to previous behaviour. See https://bugs.openjdk.java.net/browse/JDK-6996110
In any case I worked around the problem by implementing a class which reads the response as an InputStream and not worrying about base64.
Hopefully this helps a Java OAuth library user save a day of their lives banging their heads against a wall !
I want to download a document signed recipient using DocuSign API (REST).
I am using the following endpoint as per the documentation.
HTTP request
GET /v2/accounts/{accountId}/envelopes/{envelopeId}/documents/{documentId}
Request Headers
X-DocuSign-Authentication:{"Username": <Username>,"Password": <Password>,"IntegratorKey": <IntegratorKey>}
Accept: application/pdf
Content-Transfer-Encoding:base64
I got document in a base64 format which I am able to download but when try to open that file using PDF viewer we got the following message:
The file is blank and some error related to signature, check following screenshot
PDF open error snapshot
Are there any parameters missing while downloading the document? Please help.
Thanks.
See this link for EnvelopeId stamp control
https://support.docusign.com/en/articles/How-do-I-move-the-Envelope-ID-Stamp-on-my-documents
In DEMO environment you will always have the "demonstration only" stamp on the document. This will not be present when you goto prod environment
I'm trying to upload a jpeg file for profile image using the Profiles REST API to IBM Connections_v5.0. I however get an error message "The type of the photo file you provided is not supported".
I'm however able to upload the same file directly using the Connections UI interface directly. I'm setting the MIME type correctly as "image/jpeg".
Also tried with GIF and PNG images but get the same error message.
Any pointers would be very helpful.
I'm just using FF restclient addon to fire a REST call. So basically doing a PUT on /profiles/photo.do?key=....
Content-Type is set as "image/jpeg" and the payload consists of the image data in binary (base 64) encoded.
The payload should just be the binary of the image, there is no need to Base64 encode it.
You should refer to Adding a Profile Photo
You need to use a Key (great stackoverflow post here)
If you know the key for a user's profile you can do the following:
key — This is generated by Connections itself during the population
process. It is used to define the users profile within the context of
Profiles and provides Connections with the ability to associate
content with a user when the users LDAP information has been altered.
It provides a separation of identity and helps facilitate user content
synchronization for Connections.
Once you have a key, you make the following request
URL: https://profiles.enterprise.example.com/profiles/photo.do?key=
b559403a-9r32-2c81-c99w-ppq8bb69442
METHOD: PUT
CONTENT-TYPE: image/png
input the binary content on the stream
you should be able to use "image/jpeg", "image/jpg", "image/png" or "image/gif"
If you have an error after the PUT method, you should add the SystemOut.log lines which are relevant.
I have documents stored in S3 and would like to send them to docusign via REST API. I am using ruby and the standard net/http library (or Faraday, or docusign_rest gem). When sending fromS3 I am getting an error:
{
"errorCode": "NO_DOCUMENT_RECEIVED",
"message": "The document element did not contain the encoded document, or there is a problem with the encoding. Bytes for document corresponding to documentId 13 not found in request. 'documentId=<x>' possibly missing from Content-Disposition header."
}
I am hosting on Heroku so no local storage access.
Here is some relevant code...
remote_file = Faraday.get(document.filepicker_policy_url)
This retrieves the document from S3, then
post_body << remote_file.body
This should add it to the multi-part post.
You should use a ruby tempfile, and then upload from there