We are integrating a new system with DocuSign. The system is built using C# objects.
My question is, which is the best practice to interface with DocuSign - call the DocuSign Web API methods directly, or include the DocuSign C# client library as a reference to our code, and call that directly?
Thanks!
I recommend using the C# client library. It will save you time and make it very easy to use.
The code for it is also public in github, so if for some reason you want to fork and use it that way - you can do that too.
The DocuSign C# SDK saves you the bother of:
serializing the request objects into a JSON structure
sending the HTTPS request
deserializing the response objects into C# objects.
It also includes helper methods for implementing the OAuth JWT Grant flow.
These are all good reasons to use the SDK.
If you expect that you will be regularly sending documents that are above 20MB in size then you may want to implement the Envelopes::create call yourself. Why? Because the current version of the SDK BASE64 encodes the documents you upload to DocuSign.
If you implement the Envelopes::create call yourself, you can send the documents in binary. This isn't so easy to do but is important if you have very large source documents. An example of how to send in binary mode.
Added
Size limits: 25MB per API call. But document(s) in an API call that are BASE64 encoded have alot of overhead. So in this case, the effective max doc size is around 20 MB.
You can have multiple documents in an envelope. To have multiple large documents, create the envelope as a draft, then upload the additional documents as separate API calls.
See the API Limits document
Related
So we currently are creating chatbots using Google DialogFlow. The chatbots that we create are usually decision tree type chatbots that ask a particular question based on the response provided by the user. The client usually sends us flowcharts in pdf which has the decision tree and we then translate it towards creating the said chatbot and adding the relevant modules based on the information provided. Is there a way wherein I can automate some part of the chatbot creation process directly based on the decision tree sent in the PDF? The frequent updates sent by the client is a bit cumbersome so was thinking of automating it.
What I'm thinking currently is somehow converting the PDF file to some JSON format and then using that JSON file, somehow automate the process. I'm a new joiner in the company and they have given me this task to think about.
It’s possible to automate the creation process of your Dialogflow agent, however, you’ll have to create your own implementation for it. As you’ve mentioned, you can convert the PDF file into a JSON object using your own implementation, then you can use the JSON object as a reference to construct the Request Body of the methods stated below.
If you are using Dialogflow ES, then you can use one of Dialogflow ES’s Client libraries or APIs (REST API / RPC API) to create agents programmatically.
You can create ES Agents with the following methods:
REST API: projects.setAgent method
RPC API: SetAgent method
Client libraries: you can look into the documentation of each of the supported languages
After you create an ES agent, you can also add Intents, Entity Types, Contexts, etc. programmatically to manage your agent’s conversation flows.
If you are using Dialogflow CX, then you can use one of Dialogflow CX’s Client libraries or APIs (REST API / RPC API) to create agents programmatically.
You can create CX Agents with the following methods:
REST API: projects.locations.agents.create method
RPC API: CreateAgent method
Client libraries: you can look into the documentation of each of the supported languages
After you create a CX agent, you can also add Intents, Entity Types, Flows, Webhooks etc. programmatically to manage your agent’s conversation flows.
Additionally, note that your JSON Request Body must be formatted correctly based on the Resource that you’re trying to create. For example:
If you’re trying to create an ES Agent, make sure to follow the Request Body format.
If you’re trying to create a CX Agent, make sure to follow the Request Body format.
I know this is possible with Rest but would like to know if there is any way to upload Documents that are valid JSON only without the need to deserialize them and provide an object?
This is purely a performance optimization. Our SQL query returns the object as JSON and would prefer not to have to deserialize it in .Net consuming resources to be able to upload to Azure Search.
After thinking through using a custom JsonConverter scenario where I store a string and retrieve it, I have dismissed that option as probably not worth while.
No, the SDK does not support this scenario. You'd be better off writing a simple client to send your JSON to the REST API directly.
I need to upload a large file in order to request signatures from multiple signers. I'm assuming that I use the chunked upload but, I'm not sure how to tie the upload to an envelope. Does anybody have an example of how to use a chunked upload and tie to an envelope?
TIA!
If your document is about 18MB or smaller you can use the regular API / SDK calls and BASE64 encode the document so it's included in the request JSON. At this time, the SDKs always BASE64 encode documents.
For documents larger than 18 MB and smaller than 25MB, you can use the regular API calls if you include the binary version of the document using multipart encoding. See the docs. Also see working examples: Node.js example, Java example.
For documents larger than 25MB and smaller than about 50MB, you use the ChunkedUploads API methods.
I have a HTML5 static site and use Parse as the back end through REST API.
So my application id and REST API key are completely open to the public.
My classes have ACL so it should be relatively OK. But I also upload files to https://api.parse.com/1/files/ using JavaScript through REST-API .
How can I allow that only logged in users can upload files? Unlike normal classes on which I can set class wide ACL, anyone can upload files to my parsing application.
First off I would ask why you are using the REST API instead of the native JavaScript API... the JavaScript API uses the REST API under the covers, it just adds a nicer layer of interaction to work with.
Anyway, that aside you can't stop people from uploading files unfortunately. You can stop them from assigning those files to records via ACLs though, and you can do a cleanup on files that are not linked to objects.
I'm using Firebase and the SimpleLogin to allow users to login via Google, Twitter etc.
I'd like to use some of the thirdpartyuserdata object to create a user profile for my application which runs on Node.
Currently I'm posting this data to the server so that I can add to it and create the profile object, but I wondered if there's a better way of doing this - is there something I can call server side to get this thirdpartyuserdata without having to post it from the client?
Start by considering that your "server" is actually just another consumer of Firebase data. Since FirebaseSimpleLogin is simply a token generator with some fancy tools for doing OAuth, and because this happens completely client-side, there is nothing to consume about this.
If you want to consume the data at the server, you will either need to POST it, as you have done, or use Firebase to transfer the information. You'll find that a queue approach can save you a large amount of code, as this allows you to use Firebase as the API, and avoid creating RESTful services in Node, and all the baggage that comes with that.
The idea of a queue is simply that you push data into Firebase at one client and read it out (and probably delete it) at the intended recipient (in this case your node worker).