Gotcha | Posts: 44

Getting Started Questions

0 votes
Hi, Just a little bit of background first on what my objective is: We have a Web Application for Institutions used by their staff (brokers). The Application which creates legal forms with merged data in PDF. The final output is a combined set of legal forms with merged data from the back end. In the conventional approach, the broker will print the set of forms and have his client sign them, scan them with the signature and save it back to the application as a digital attachment into the Web Application for future references or auditing trail. I've taken a look at the 2 blogs how to create and how to check package status and the available methods with REST. In our modified work flow, here are the places we've identified where the Signature API are required. (Can you identify the Web REST Methods I need in each case?) 1. On creation of new Form Set for a New Application, We need to call a method to Upload our Merged PDF which has predefined (Text Fields) fields over signature area (where a Signature is required) in different parts of the set of forms - ie multiple forms. This is also where we will send all the info of the Signing parties required- Example : We can have 2 applicants with their respective emails on the application and as such require both their signatures each in a specific area across the forms. 2. We also need a way to to retrieve the Signing URL ( I understand , the default , an email is privately sent to the applicants ) which our Web Application can retrieve and present them . The Applicants can be either remotely in which case the private email for signing will be used OR in front of the broker doing the application. In the latter case, we plan on retrieving the Signing URL to present them to the applicants on a mobile device like a Tablet which will sum up basically the Application AND provide them the option to sign over eSignLIve but on the Broker's Tablet. 3. On reviewing an existing Application, If a previous Signing Event was submitted but not completed by all parties, we need a way to identify the status and present the broker with either a "COMPLETED" Status or Retrieve the Signing URL ( as #2 above ) 4. When all parties has completed the signing process on a particular Application, we need to be able to download the SIGNED documents - ideally automatically PUSH from your Web Services or on demand from our Web Application. Finally, once downloaded, we would deleted the forms from your server. 5. Our Application supports multiple Institution with brokers working for them. We would probably support 2 types of set up:
  • a. a Single eSignLive Front end... where ALL Institutions forms are stored on one Account ( ours ). We figured , the institutions , wouldn't necessarily need a Front end to ESignLive as they are only concerned with the Capturing of the Signature and Archiving it in our Application
  • b. Each Institution who would like to use your Front end for all their ESignatures outside those we generate in our application.
Do you foresee any caveats or precautions i need to take care - example: In the case of a Single Set up, is there a way to send an InstitutionId to your WebS so that we can distinctively identify which Institution are the forms from - I would probably need a filter by this InstitutionId in the Front End. Also, is the Auth Token will be the different for each Institution, if we do the multiple Accounts. I'm just getting my feet wet .... trying to identify the different web methods i need to consume based on our work flow ...etc. Based on my workflow, I've identified 5 calls which I'll be using - POST /packages Can I send only one call with all the Applicants Info , Upload the Binary or do I need multiple REST calls ? How do I send References from our Applications like the InstitutionId and the Application Number where these can be searched on or filtered on your UI? - GET /packages/{packageId}/roles/{roleId}/signingUrl : Is the RoleId generated by your system returned to me on the POST/packages - since this is where I first send the applicants within the or is it our own unique Id which we pass to you? -GET /packages/{packageId}/signingStatus: How do I check who hasn't signed? - GET /packages/{packageId}/documents/zip -DELETE /packages/{packageId} SNIPPETS & SAMPLE CLASSES: From your example blog, I saw you created the JSON payload from scratch - using the string. Would you have a complete JSON ( which I can use to construct a class) or CLASS which I can use to serialize directly ( I'm using C#) for the package method? Similar, would you have one for the response which will define all the possible nodes and their enumerations ( exampl different status SENT, SIGNING_COMPLETED, etc ) Thanks

harishaidary | Posts: 1812

Reply to: Getting Started Questions

0 votes
Hey Cyril, I will answer your questions numerically for readability: 1. To retain your PDF form fields and signatures in eSignLive, you will need to use document extraction. Your form fields need to be named how eSignLive can recognize them. You can find a complete example of this on our Code Share https://developer.esignlive.com/code-share/document-extraction-rest-api/. You can also follow this blog: https://www.esignlive.com/blog/e-signlive-how-to-document-extraction-net-sdk/. You can do this in a single call. 2. After sending your package, to get the signing url, you will need to do a GET call to following url: https://sandbox.e-signlive.com/api/packages/{packageId}/roles/{roleId}/signingUrl. The packageId is returned to you when you create your package. For the roleId, you can manually assign one in your “roles” object. You can find an example on how to set a role id in the “how to create and send a package with the REST API” blog: https://www.esignlive.com/blog/e-signlive-for-new-users-how-to-create-and-send-your-first-package-rest-api/. The roleId is set under “roles” > “id”. 3. Retrieving the signing status will return you “COMPLETE” if the signing has been completed by all signers or “SIGNING_PENDING” otherwise. Unfortunately, this is only on a package level and not on a signer level. You will have to keep track of this on your side. One way I can suggest you is to setup callback event notifications and register for the “SIGNER_COMPLETE” event. This way, whenever a signer has completed signing all documents, you will receive the following callback notification to the url you specify: { "name": "SIGNER_COMPLETE", "sessionUser": "{roleId}", "packageId": "packageId" } With this information, you can easily track who hasn’t signed your documents. For more information on setting up callback event notifications, have a look at this blog: https://www.esignlive.com/blog/e-signlive-how-to-setting-up-callbacks/ 4. Downloading documents has been covered in the “Check Package Status and Download Files” blog: https://www.esignlive.com/blog/e-signlive-for-new-users-check-package-status-and-download-files-rest-api/ 5. Every package you create with eSignLive, a unique package identifier is returned to you. Again, you will have to keep track of this on your side to figure out from which institution each package is created from. Also, every authentication token you create will be unique. Snippets and Sample Classes: You can search through the REST API forum to find examples and questions asked by other developers. You can also head over to our Code Share section to find a few examples. We continually seed examples in the Code Share for the REST API, Java SDK, and .NET SDK. As for the complete JSON request with every single node and enumeration, you can get it by creating a package through the web ui/SDKs and doing a simple GET package call (e.g. GET https://sandbox.e-signlive.com/api/packages/{packageId}) Let me know if you have further questions or if anything is left unclear :)

Gotcha | Posts: 44

Reply to: Getting Started Questions

0 votes
Hi Haris Thanks for your prompt reply :
"5. Every package you create with eSignLive, a unique package identifier is returned to you. Again, you will have to keep track of this on your side to figure out from which institution each package is created from. Also, every authentication token you create will be unique."
5.1 Can you tell me how and where I would send 2 references to the package; our Application Reference No and Vendor Code ? These will be a references to our Application ( example a unique number the brokers will know to which the Application came from). 5.2 Also can we do a search by the 2 references in question. The use case scenario , Assuming One eSignLive Account which holds ALL forms from various Institution which we ( the Vendor ) manages. This will be exceptional cases, when there is a need to check if any pending forms that needs to be cancelled/modified . It would be great to have a filter on those custom references given that there may be a lot of pending forms in the Inbox. 5.3 What do you mean by "authentication token you create will be unique." is that the "apiKey" used in Client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", apiKey); ? Since we are looking for both possibilities ; a Single Account ( Vendor's account) and a Multiple Account ( Institution's Account) . In the case of the former, I'm using the API KEY from my Developer Account. So I'm guessing the Latter, I need to ask the Insitution to provide me with their API Key ? With regards to the sample classes... Can you point me to the link which has the OBJECTS/CLASSES ? I did a search on "Serialize, Deserialize" I couldnt find anything in the forum or code share ?

harishaidary | Posts: 1812

Reply to: Getting Started Questions

0 votes
5.1 Unfortunately, this is not possible. What I can suggest you is to create a sender in your eSignLive account for each of your institution. This way, you can send packages from your senders (institutions) and later retrieve the sender information from each package to determine your institution. I think this is the viable way to achieve what you want. You won't need to have multiple accounts for your institutions. 5.2 Refer to 5.1 5.3 The api key is used to in authorization header to authenticate yourself to eSignLive. This is unique to your account. Once you have your senders, you can use the same api key to create and send packages from your senders since the senders are linked under your account. Finally, there aren't sample classes per say. But you can try what I mentioned previously to get the complete JSON to create your own: create a package from web/ui or through the .NET SDK and do a simple GET https://sandbox.e-signlive.com/api/packages/{packageId}

Gotcha | Posts: 44

Reply to: Getting Started Questions

0 votes
5.1 Ok, I know i sound like a broken record but I want to make sure that there is no way to apply a tag or reference back to the originating Web Application ? This will allow us to put some context tagged onto the package we upload to eSignLive. Specially since we will be using a Single Account to host multiple Institutions and once it is uploaded, i'm guessing it would be good to have some context of the packages since all will be ending in the same account. I will certainly look into the predefined "Senders per Institution" . One question related to this option - Can the "Senders" be created using the REST API on the fly or Do I have to create it (ONCE) before we start interfacing to you? 5.2 With regards to Multiple Accounts, I'm covering those Institutions who already have an eSignLive Account with you or for some reason would insist on having their own eSignLive account. In this case, given that they are also using our Web Application to request Signed documents , we would have to direct the package to their Account, right? In this case, which token/apiKey do I use?

harishaidary | Posts: 1812

Reply to: Getting Started Questions

0 votes
5.1 The only way you can retrieve packages from eSignLive is with the package id that is returned to you when the package is created. With that being said, I can suggest you two things:
  1. You can create a label field or a custom field with eSignLive and set the label field id or custom field id with the application reference # or vendor id and subsequently apply it on your document. After which, you can retrieve the package using the package id and search through the JSON to retrieve the application reference # or vendor id.
  2. You could keep track of the vendor id / application reference # in your application with every package that gets created. Hence, with the package id you could do a simple search in your application to identify your Institutions with the vendor id / application reference #.
As for the senders, they will have to be added before creating/sending packages. You can follow this blog on how to add/send packages through your senders: https://www.esignlive.com/blog/esignlive-how-to-managing-senders/ 5.2 If your institutions insist on having their own account and want to use your application, you will have to use their api key. Note that by doing so, you will not have access to those packages since they will not be created under your eSignLive account. Your institutions will have to delegate access their account to you to retrieve the packages: https://www.esignlive.com/blog/esignlive-how-to-delegating-access/

Hello! Looks like you're enjoying the discussion, but haven't signed up for an account.

When you create an account, we remember exactly what you've read, so you always come right back where you left off