We're using Python and the Requests library to add PDFs to DocuSign envelopes using the Add document method of the REST API v2:
response = requests.put(
'<base URL>/envelopes/<envelope ID>/documents/<next document ID>',
files={'document': <the PDF file object>}, # <- added to the request's body
headers=self._get_headers(
{
'Content-Disposition': 'document; filename="the-file.pdf";'
}
),
timeout=60
)
This has worked for us in most cases, except that about 1 in 100 PDFs isn't accepted via the API. When this problem occurs we tell our users to upload the PDFs directly through the DocuSign UI, which works. This prompted us (with the help of support) to look at the Document params link that appears above the example request on the Add document page linked above. The page shows a documentBase64 attribute, and a number of other fields. How can I supply the document in this format, with all the fields specified? Should I replace the file in my call above with files={'document': <JSON-encoded object>} or? I can't figure out how to add a document OTHER than the way we're currently doing it. Is there another way I'm missing?
It looks like there are now two different ways to add a document to a Draft Envelope with the REST API:
Use a multi-part request, where the first part contains the JSON body and each subsequent part contains a document's bytes -- in un-encoded format. An example of this approach is shown on pages 136-137 of the REST API guide (http://www.docusign.com/sites/default/files/REST_API_Guide_v2.pdf).
Use a normal request (i.e., not multi-part request), and supply document bytes in base64-encoded format as the value of the documentBase64 property for each document object in the Request. (This looks to be new as of the recent December 2013 API release/update.)
Based on the info you've included in your question, I suspect you're currently using approach #1. As described above, the main difference between the two approaches is the general structure of the request, and ALSO -- approach #1 expects document bytes to be un-encoded, while approach #2 expects document bytes to be base64-encoded. I suspect your issue has to do with encoding of files. i.e., if you're using approach #1 and any of the files are encoded, you'll likely have issues.
Related
I have asked this question on https://community.adobe.com/ and have not received an answer. If I do, I will include the response here.
I am able to create a pdf using the basic approach outlined by adobe at https://developer.adobe.com/document-services/docs/overview/document-generation-api/
Ideally, I don't want to have to send the base docx word document across in the api call each time I generate a new pdf. I would rather host the docx which can be retrieved at document generation time. One approach would be a reference url to a docx hosted on acrobat.adobe.com. At the moment I have to send the docx as well as the json data which seems inefficient.
I am using https://cpf-ue1.adobe.io/ops/:create
"cpf:inputs":{
"documentIn":{
"dc:format":"application/vnd.openxmlformats-officedocument.wordprocessingml.document",
"cpf:location":"InputFile0"
},
I guess if it can't be done, then that's okay, I just would like to know so I can implement accordingly.
thank you
I'm trying to use a logicapp to get the content of an email and post it to slack. By content I mean:
the body of the email and other elements like From:, Subject:
any attachment in the email (which usually are binary like PDF, Excel, image)
the email itself saved in a blob as .eml file
Slack chat.postMessage API works without any problem to send any text element. This API has some attachment argument but doesn't seemto be designed or binary files (or not for files at all, only strings)
I've tried slack files.upload one but couldn't figure out the syntax, especially the syntax using a regular HTTP POST. Could find examples online using curl, Python, JS and C# SDK but I don't know how to translate them to HTTP POST just like I do with chat.PostMessage
I've tried the API on SOAP UI, using file as argument as per the documentation, and I've used it in different sections: in the header, in the body, and using the Attachment Tab, none of the work and always the same error message : no_file_data
Unfortuatelly slack documentation lacks of details. Here's what it says about files.upload:
You must provide either a file or content parameter.
The content of the file can either be posted using an enctype of multipart/form-data (with the file parameter named file), in the usual way that files are uploaded via the browser, or the content of the file can be sent as a POST var called content. The latter should be used for creating a "file" from a long message/paste and forces "editable" mode.
In both cases, the type of data in the file will be intuited from the
filename and the magic bytes in the file, for supported formats.
I could use alternatives like just saving the attachments in blobs and use Azure functions to send the file, but I want to understand what's the limitations before changing the method.
Any clue?
I'm attempting to create a REST API method that accepts multiple file uploads with some additional arguments. This API method will be called from both web forms, web services or mobile apps.
Is there a standard I should be following with regards to how the method takes these parameters in?
So far, I've considered the following two approaches:
JSON body: file data to be included as base64 encoded fields within the JSON object. Fine if being called from other web services, but troublesome when calling from a HTML form?
multipart/form-data: easy to use with HTML forms, but problematic when calling from web services or mobile apps?
I know that either of the two approaches would work, but I'd like to implement this the correct way (if there is one) according to current standards. Any ideas?
Do modern JS libraries/frameworks make it easy to POST HTML forms to web APIs as JSON objects
Yes, we have a lot of library to convert the file into base64.
In my opinion, choose what is based on your requirement. Firstly, exchanging data in multipart format should be more efficient than base64 json string. But this article show, the term of the size is little.
But if we use json, you could pass multiple other variable in the json format and we could read it easily.
Besides, if your file is image, the browser understand data URIs (base64 encoded images), there is no need to transform these if the client is a browser.
I read this question - Multi-page document as images over REST which has very nice answer. We have similar scenario but with some additional requirement.
The request can either return the document as binary data or upload the pdf/jpeg(s) somewhere and return a URL to the uploaded file.
How should the calls be different? What is coming to my mind is to use GET for the binary data response and POST when it uploads and returns URL. When it is POST it will return 201 (Created) and return the URL to the uploaded document.
There is also one more detail about the first point. When uploading and returning a URL we can either upload for a temporary usage (and delete it after some time) or make it permanent. Should we do this by adding query parameter? like - POST /documents/12345.pdf?permanent=true
As in the original question, we also return different jpeg for every page. But the process of creating the document is time consuming so we want to take all pages at one request. What would be the proper way of doing this? I think in the 201 response you can only return one URL.
Is the GET /documents/12345.pdf approach a good alternative of the accept header or there are also other approaches? Would using the slash instead of dot be better, like GET /documents/12345/pdf? This way it wouldn't be needed to parse the "12345.pdf" string.
Thanks!
I've learned a thing or two in the past two years lets see if I can take a stab at this...
You can make the POST request always return the URI of the newly created resource. Do you ever need the POST to return the binary if you're the one providing it in the first place? I think I'm tracking with you in this case the GET would return the binary and the POST would create the resource and return the location (URI) of the newly created resource.
This isn't RESTful as GETs should be safe (GETs don't modify resources). You could make it a PUT if you want to update the status after the fact or when you POST you could add a flag in the request body to mark it should be permanent. Info on POSTing an image and data can be found here
For #3 do you want to fetch or upload everything in one request? You can return whatever you want in the response. You could structure your request in such a way to return a json array of urls. For example if you structure your request similar to my example then GET /documents/12345/1 may return page 1 of document 12345 while GET /documents/12345 may return all pages to document 12345.
For #4 I wouldn't do /pdf as that represents resource hierarchy. PDF is only the representation of the document, not the actual document. I would vote querystring since there may be other attributes. For example imagine trying to do the following with slashes... GET /documents/12345?format=pdf&color=grayscale&quality=300dpi&layout=portrait
I have a DESKTOP application which interacts with a web service through their RESTful api and OAuth 1.0. I can use all the resources fine, authentication, get/post calls to retrieve and send simple text data etc, no problems there.
However, I'm struggling to send binary data. The service allows sending pictures. For one part, they have a non-OAuth api through which you can also send a file in plain binary, simply pass some params in the URL and put the entire binary file in the post.
Now to do this through the OAuth api, becomes an issue:
The service specifies the post needs 2 parameters (not to be included in the URL since this is REST, but in the POST parameters):
image A binary file, base64 data, or a URL
type The type of file that's being sent in. Accepted values: file, base64, url
So we have 2 parameters: image contains the file itself, and type would be "file" to specify binary. But how am I supposed to include this through OAuth? given that the -image- and -type- parameters (and their values) must be used to generate the base string for the signature, which is matched against the parameters included in the POST.. I can't include the entire binary there as a value for the image parameter; so how is it done in this case?
nvm, their OAuth api expects the file as multipart/form-data with the variables there, and none in the base string for the signature (their non-OAuth api instead doesn't need multipart, so I expected their OAuth wouldn't either; their documentation is a bit lacking in this area).