programmableweb's esignature api research report

ProgrammableWeb Report: APIs for eSignature Products 1

APIs for e-Signature Products

ProgrammableWeb REPORT

2 ProgrammableWeb Report: APIs for eSignature Products


APIs for e-Signature Products: Introduction

In the last few years, e-signature products have helped to automate a tedious, time-consuming, costly and very common task: signing documents. The need to circulate physical documents and obtain signatures on them creates delays and the potential for error in many business processes, particularly sales. E-signature products put the process online, and now APIs are enabling companies to integrate the electronic signature process directly into their workflow.

In this report we present the results of our evaluation of seven e-signature services:

Adobe EchoSign RightSignatureBarracuda SignNow Sertifi eSignatureDocuSign Silanis e-Sign LiveHelloSign

Six of the services have REST APIs, including two that also have SOAP, and one of the services is SOAP-only.

It’s hard to look closely at these products and not conclude that DocuSign is in a class by itself. The DocuSign API is far more comprehensive than the rest. The documentation, sample code, tools and community are superior to that of all the other products. And no other product came close in terms of support for multiple languages, particularly with respect to sample code.

HelloSign and Sertifi e-Sign Live are also strong contenders. HelloSign, in particular, was very easy to get up and running in our tests and had excellent documentation. Sertifi e-Sign Live, the one SOAP-only product we tested, was also easy to work with. There were problems with its documentation, but, due to the nature of SOAP, these issues weren’t as thorny as they would have been with REST.

The others—Adobe EchoSign, Barracuda SignNow, RightSignature and Silanis e-Sign Live—were all disappointing in tests. While each has some merits, their documentation was brief and/or confusing. None of them had adequate sample code, although some had SDKs and samples for .NET and/or Java. Still, if you want to use these products by programming the APIs directly, we found all of them to be severely lacking in what we think makes for a great API and developer experience.

We evaluated the products from a programmer’s perspective, focusing on features that would help a company to use the API quickly and effectively. We considered the availability of evaluation accounts for programming tests, the quality and availability of documentation and sample code, tools for programmers and community for support. A more extensive discussion of our testing philosophy follows in the “What Matters to Us” section.


What do these products do?The seven e-signature products we tested are cloud services that at their most basic level provide two main capabilities:

• They collect electronic signatures in some form from a user and incorporate the signatures into a document

• They manage workflow by routing the document for review and/or signature from other users, based on rules set by the developer and/or administrator

Some of the products we tested go further—providing forms control, for example—but signatures and workflow are at the core of all the products. All of the services we tested have an interactive product that allows users to perform basic e-signature functions with no programming. But they all also provide an API that allows organizations to build these functions into their own applications.

It is important to note that there are differentiating factors among these products that are not evident at all in the APIs. Indeed, the API serves in large part to hide implementation differences from the programmer.

REST vs. SOAP, JSON vs. XMLAs in the rest of the world of APIs, SOAP is declining as a technique among e-signature products, and REST is ascendant. The same is true, to a lesser extent, of JSON (on the rise) and XML (going out of favor).

One of the products we tested, Sertifi eSignature, has only a SOAP API. Barracuda SignNow, HelloSign, RightSignature and Silanis e-Sign Live have only a REST API. DocuSign and Adobe EchoSign have both. In the case of DocuSign and EchoSign, we tested only the REST APIs. Both DocuSign and Adobe claim that their SOAP and REST APIs provide equivalent functionality.

API Types

Adobe Echo Sign

Barracuda SignNow

DocuSign HelloSign Right Signature

Sertifi eSignature

Silanis e-Sign Live

REST 4 4 4 4 4 4

SOAP 4 4 4

Request and response data is another case where it’s easy to see which way the wind blows. Sertifi eSignature is, by nature of using SOAP, reliant on XML for both request and response data. The REST products support JSON in nearly all cases, although some also support XML.

E-signatures vs. digital signaturesA common point of confusion, sometimes even in vendor marketing, is the distinction between e-signatures and digital signatures.

E-signatures, which are the core function of the products we evaluated, are a digital analog of a signature that a person signs with a pen on paper. Sometimes it is a literal graphical image of the person’s signature, but it can also be simply a digital statement of some kind that a specific person signed a document.


The United States and many other countries have adapted laws to make these sorts of signatures acceptable in a wide variety of cases, such as signing contracts, government forms and deeds to property. E-signatures are not a particularly strong method of authentication, but then neither is a signature written with pen on paper.

Digital signatures are data created to strongly connect a block of data with a particular identity. For instance, the digital signature of an e-mail message can be used to prove to the recipient that the message did, in fact, come from the apparent sender and that it was not modified after it was signed. There is a role for digital signatures in e-signature products, but most products do not bother with them and instead use simpler techniques to identify documents and verify document integrity.

Pre-built integrationsIt may be hard to believe, but not everyone wants (or is able) to write code. Fortunately, for these situations, each of the products we tested provides pre-built integrations with other cloud services.

At the simplest level, these integrations allow the e-signature service to read or write documents on another service—say, DropBox. Business applications like Salesforce and Microsoft Dynamics CRM are obvious targets for e-signing because contracts and other agreements are so central to their operation, and several of the products do work specifically with them. DocuSign and Microsoft also recently announced a partnership to make DocuSign available within Office 365. We did not study these integrations as part of our evaluation, but for many companies, the integrations will be an easier solution than writing their own code.

How we compared the products and APIsIn tests, we approached each of these services as a developer would.

We checked the developer facilities at each. Is it easy to find documentation for the API? Can you get an eval account? Can you actually test the APIs and the entire environment without signing up? How good is developer support and community? Is quality sample code available?

We also tested some of the APIs for each service to get a feel for working with them. We looked at each API and the API set as a whole for design quality. We checked with the vendor and community to see if the company has policies for adding and retiring API features.

One can argue that any platform that can make HTTP calls can support any of these products, but that’s a pretty low standard. (In fact, for SOAP, not even HTTP is necessarily required.) We expect more from a development system than just an API specification. Indeed, an API spec just isn’t enough in a world in which numerous languages and operating systems are used to access APIs. Still, some of the products provide a higher level of support to a broader range of programming platforms: PHP, Java, .NET, Ruby and Python are some of the platforms and languages we encountered.

It’s important to make a distinction between what an e-signature provider can do and what is made available via its API. This report is focused on the API because we believe this is how the e-signature industry will continue to expand—through both internal and developer usage of provider APIs to help automate and integrate e-signatures into business workflows.


Warning: Features may shift as you work on themWe want to make it clear that this report represents a snapshot in time—and we all know how much things can change from one minute to the next. After all, this is the cloud we’re talking about: Features, documentation and anything else may change at any time. Good companies provide clear and advance notice of such changes, but it’s not like you have to run apt-get for the changes to happen.

Several vendors told us that important changes in the APIs and documentation would be rolled out around the time of our evaluation. We have noted these where applicable.

What matters to usWe prepared this analysis with the interests of programmers in mind—and web API programmers in particular. To that end, we focused our analysis on the breadth of the API itself and on the features and functions that help web API programmers do their work more efficiently.

These included:

• Documentation: We consider great documentation to be very important. Documentation should explain in detail the API, its methods, the JSON or XML schema, and other important factors.

• Code samples: The vendor should offer lots of code samples in the major languages used to write web and mobile apps: JavaScript, PHP, Python, Ruby, Java, Objective-C, and C# and other .Net languages. It should also show how to use cURL or some other interactive test tool for the API’s endpoints, except in the case where SDKs are the primary method of access.

• Interactive consoles: Interactive consoles, sometimes called playgrounds, are good for developers. Many API providers, including two in this comparison, offer Web-based tools that allow a developer to test the many different types of calls and methods interactively using forms and wizards.

We think it’s important for developers to be able to at least minimally poke at an API in some way without having to go through any sort of lengthy registration or paying a fee. It’s fine if that access is provided using only sample data, and we also think it’s fair that vendors take special measures—such as watermarking documents created with eval accounts—to prevent the documents from being used for production. But taking the API for an actual spin is an important part of the discovery and evaluation process, and API providers need to know that developers are more likely to go with a company that offers this capability.

• SDKs and libraries: SDKs and/or libraries for the languages listed above (including support for Node.js) are a huge plus.

Web APIs began with SOAP and XML, but these have gone out of favor in recent times. The new de-facto standard for web APIs is to use REST and JSON. These are considerably simpler than SOAP and XML. Some may argue that SOAP and XML are more versatile, but the market has spoken. Two of the products we evaluated—Adobe EchoSign and DocuSign—offer both SOAP/XML and REST/JSON; all the customer action is with the latter, according to vendors we spoke to while conducting this study.

If an SDK is the main programming interface, then these issues may not be as important. For example, while it isn’t an e-signature service, Evernote is an example of an API that doesn’t even support REST/JSON. That hardly matters because all of its developers go through SDKs. (Evernote uses Apache Thrift to generate these SDKs.)


How the products stack up

Adobe EchoSign

Product Home Page: https://www.echosign.adobe.com/

Developer Portal: https://www.echosign.adobe.com/en/products/echosign-api-dev-center.html

You’ve heard of Adobe, and that counts for something. EchoSign has some good features and, by the standards of this market segment, is a mature product. Adobe has not, however, taken the time to create what developers need to use EchoSign well.

Developers can sign up for a free developer account at the developer portal. There are no constraints on time or number of documents. But documents are watermarked to prevent production use. Adobe makes it easy to get an API key from the Account tab on the Developer portal. EchoSign has both REST and SOAP APIs, and both request and response data can be in JSON or XML.

EchoSign has good audit trail functionality. Exposing the feature through the API allows companies to ensure that transactions are archived, for legal and other compliance reasons.

There are three different types of keys that can be used with EchoSign: user-specific keys, organization-specific keys and application-specific keys. This adds some programming complexity, but it could provide useful flexibility for keeping billing organized. A good reporting system could accomplish the same thing, but using keys automatically separates charges. Only Adobe has this capability automatically, although other vendors would probably make arrangements for multiple keys if you asked for them.

Like DocuSign, EchoSign includes a tool, called Try It Out, for testing APIs interactively. However, while DocuSign’s API Explorer includes a developer-friendly form for populating JSON-based requests, EchoSign’s tool requires hand-coding of literals into a single field that includes all of the JSON (which awkwardly wraps when the lines get too long, interfering with readability). The former approach is better for entering name/value pairs, while the latter is better for developers who want to cut and paste their JSON from some other editor or app.

EchoSign’s interactive interface included one nice touch: It lists all of the HTTP error codes that the API could return, as well as what each means.

The really unfortunate problem with EchoSign is the dearth of help for REST developers. The documentation consists of the API Explorer itself and a PDF with fewer than five pages of content. The only sample code provided for the REST API is in Java.

Documentation for the SOAP API is better, but still nothing special. There is one set of trivial SOAP code samples for C#, Perl, PHP, Ruby and Java. Adobe calls this set of sample programs an “SDK,” but it’s not worthy of the acronym.

In addition, Adobe has not yet created any developer community features. Developer support is handled through standard Adobe support, and there is some EchoSign action at StackOverflow. However, there are no organized developer forums for EchoSign. This places it on par with most of the other products. Only DocuSign and Sertifi put any effort into providing dedicated communities for developers.


Barracuda SignNow

Product Home Page: https://signnow.com/

Developer Portal: http://developers.signnow.com/

SignNow from Barracuda—best known for its security products but diversifying rapidly—looked simple to us at first glance. How wrong we were. To put it generously, SignNow is still under construction.

On our own, we were unable to make a single successful call with the SignNow API. The root cause, as it were, was insufficient and confusing documentation, and the absence of community features didn’t help.

Very late in testing, a Ruby SDK and Ruby library for OAuth 2 authentication appeared on the site, but for the rest of the time, Barracuda provided only one example program (written in C). The API documentation itself includes a cURL sample command. We really would have preferred PHP or JavaScript, but it might not have made a difference.

Late in the production of this report, Barracuda notified us of features that were available but undocumented. The company offered to send us the documentation and put it online, but our deadline for testing the APIs had passed. As we’ve already said, these are cloud services, and features in any of them can change on a moment’s notice. Readers of this report are encouraged to double-check with the API providers to see what, if anything, has changed.

Applications written to take advantage of SignNow’s e-signature services use a basic authentication call (username:password) in order to retrieve a bearer access token. This token is then used for subsequent commands.

SignNow appears to be the only product in this comparison that supports three-legged OAuth authentication, which would allow a third-party authentication.


DocuSign

Product Home Page: https://www.docusign.com/

Developer Portal: http://www.docusign.com/developer-center

To put at least one difference between DocuSign and the other products in perspective, one need only compare API calls: With the exception of Sertifi eSignature, the other products reviewed in this report have about 10 to 20 API calls. DocuSign has about 130. You can see in the section on the API feature set that this translates into access to a large variety of capabilities that the other products simply can’t offer.

Some examples of features accessible through the API that are unavailable elsewhere are:

• Offline Signing: Going from an offline to online scenario (that is, start an envelope offline, build it and configure it to upload once back online)

• Formula Tabs: This feature provides the ability to reference other fields and do basic calculations (+, -, *, /)

• Customized branding: DocuSign gives companies the ability to customize the signing experience to a greater degree than other products

• Authentication abundance: DocuSign has the widest variety of options for authentication of signers, including digital certificates, voice phone call and geolocation

The benefits of all these features are clear: Developers integrating e-signing functionality into their software have more possibilities with DocuSign. Also, in many cases, the APIs are not new signing features but ancillary features that developers would otherwise have to implement on their own or, more likely, rely on from an outside product like Acrobat. These include numerous page and form manipulation features, such as manipulating fields, and even the ability to rotate a page image from a document.

Like Adobe EchoSign, DocuSign has both SOAP and REST APIs. The REST APIs support JSON and XML for both request and response. The SOAP APIs, like all SOAP APIs, support only XML.

DocuSign’s documentation and developer tools are first-rate. Indeed, they are head-and-shoulders above those of the other products we tested. As with Adobe EchoSign, DocuSign offers an API test tool that enables developers to interactively fill in values and execute a call. With that said, DocuSign API Explorer has some clear advantages over Adobe’s REST Try It Out tool. The main one is that DocuSign API Explorer opens up fields in which developers can enter values in a JSON record; with EchoSign, you have to manually write JSON record constants.

Where DocuSign clearly stands out is in documentation and sample code. The other products we tested provide very little in the way of sample code, and usually in just one or two languages. DocuSign’s API WalkThroughs provide illustrations of the API flow and sample code for nine common scenarios, including Request Signature via Template, Get Envelope Recipient Status and Get Document List & Download Docs. Sample code is provided in PHP, JavaScript, Java, C#, Python and Objective-C. This will save many a developer a lot of time getting up and running.

Obtaining a development account and an API key for DocuSign is easy: Simply sign up for a free developer eval account, and you will get an API username and account ID. A demo integrator key is then just a click away.


DocuSign has no formal community on its site, instead sending developers to StackOverflow, a more general-interest development community where representatives from DocuSign monitor the activity. This seems to work well, especially if you have other development community interests that are covered by StackOverflow.

DocuSign does what it can to make its API quickly accessible to developers, but the breadth of the DocuSign API does make it more complicated. If it weren’t for the sample code, it would be more complicated to get that first app up and running. DocuSign’s sample code helps. But a longer learning curve is the price that’s paid for the DocuSign API’s superior feature set.

We did run into some problems with our DocuSign testing. We ran into cURL SSL Cert errors, probably because DocuSign had to add a client PublicKey to its server table and enable Certificate-Based Authentication for our DocuSign account. We weren’t able to get this resolved before testing was complete. This problem may not happen with paid accounts.

We also had trouble using JSON in the X-DocuSign-Authentication header for API authentication. XML worked for us. Due to time limitations, we didn’t pursue this as far as we might have, and threads on StackOverflow indicate that others use JSON with no problem.


HelloSign

Product Home Page: https://www.hellosign.com/

Developer Portal: https://www.hellosign.com/api/gettingStarted

HelloSign was the easiest product we tested in terms of getting up and running quickly with APIs. The documentation is well-designed and readable. All calls include cURL command examples with thorough JSON enumerations. We also were able to use the Postman REST client for testing.

We got an API key from HelloSign, but, surprisingly, the key wasn’t strictly necessary—you can make all calls with just username:password. The company says it is attempting to move developers away from this model and toward using keys.

The HelloSign platform provides five walkthroughs: for signature requests, templates, embedded signing, events and callbacks, and OAuth 2.0. These are very useful as documentation, but no sample code as such is provided; all the examples show cURL. As a result, it took us longer than it should have to get a PHP script up and running to make API calls.

HelloSign also provides a client library for Java and links to third-party libraries for Ruby and .Net. Had we used one of these, we might have gotten up and running more quickly, but none of these provides real sample programs. The Java library includes a few code fragments, and the others provide one each. This is a relative weakness for HelloSign, but we were able to overcome it with reasonable speed.

HelloSign does not have free developer accounts, but all of its plans come with a 30-day free trial. This is probably what disappointed us most about HelloSign: Sometimes you just get busy, and 30 days isn’t enough. The HelloSign model does not make sense, especially since signature requests will be watermarked as tests and not legally binding without a paid account. This is all the more reason to give developers more freedom. Nor does HelloSign have any community features. The company would do well to move to a more developer-friendly model.

With all of that said, HelloSign made a surprisingly good impression on us for a product we’d never heard of from a small and relatively new company.


RightSignature

Product Home Page: https://rightsignature.com

Developer Portal: https://rightsignature.com/apidocs/overview

RightSignature is one of the more mature products out there, but we found it confusing. From the API point of view, it is atypical in many ways and difficult to get up and running. The documentation sends mixed signals and, considering how long RightSignature has been around, should be more comprehensive.

Authentication with RightSignature appears to require the use of OAuth. We gave it a try, but were unable to get past a lot of “Invalid OAuth Request” errors. There is documentation and sample code for authentication via OAuth and a secure token (a long encoded string provided by RightSignature), but we couldn’t get it to work. Indeed, this organization kept us from testing the APIs interactively with cURL, Postman or anything else.

Oddly, sample code for the authentication process is provided (Ruby, Java, PHP, Python and C#), but there is no general documentation of the process. The APIs themselves have better, but still skimpy, documentation. There are no JSON examples, and the XML is illustrated only with examples, not a description (although the examples seem adequate). RightSignature has no community features.

There are two sample programs: a perfunctory one in Java and a more substantial one in PHP. We gave the PHP example the old college try, but it requires the creation of a MySQL database.

RightSignature API request data must be XML, but the response can be either in XML or JSON. This seems like an odd state of affairs, and we can only assume that JSON will eventually be available as a request format.


Sertifi eSignature

Product Home Page: http://www.sertifi.com/

Developer Portal: https://sertifi.zendesk.com/forums

Sertifi eSignature is the only product in this comparison that provides only SOAP APIs. Sertifi says it will be releasing a REST API in the second quarter of 2014, but it was unavailable for testing at the time we compiled this report. This makes a direct comparison to the other products tricky, but we’ll do our best.

Sertifi is designed to ease the stress of implementation and, for the most part in our tests, it lived up to that promise. With the exception of DocuSign, Sertifi also has the most extensive API we tested.

Documentation for SOAP APIs is still important. But an associated technology, WSDL (Web Service Description Language), serves some of the same purposes. SOAP tools read the provider’s WSDL to build documentation directly into the process. Using the API is a matter of filling in the fields described by the WSDL.

We used the well-known free SOAP utility SoapUI and the one WSDL gateway that was included in the API Developer’s Kit, along with the customer API key. With these, we were able to generate all the required method operations for the majority of functionality needed.

Sertifi does not advertise free developer accounts on its web sites, but the company told us it will give an evaluation sandbox to anyone who asks for it.

Excellent API documentation was available both in HTML and PDF. Sample code is available for C# and PHP and is perfunctory, touching only one or two API calls apiece.

Overall, Sertifi made a good impression as straightforward and usable, although the WSDL contained methods that weren’t in the documentation. We didn’t test every one of the API’s methods, so we can’t say just how serious this problem is. Seasoned SOAP developers tend to rely on WSDL rather than the documentation, and might not even notice the discrepancy.

Sertifi uses ZenDesk for support, including a discussion forum and knowledge base. Both are sufficient and functional, and more than most other vendors provide.


Silanis e-Sign Live

Product Home Page: http://www.silanis.com/

Developer Portal: http://www.developers.silanis.com/

API Documentation: http://docs.e-signlive.com/doku.php?id=esl:e-signlive_api-routes

JSON Schema: http://docs.e-signlive.com/10.0/schema/index.html

Silanis comes to the e-signing game from an enterprise background—specifically, banking and insurance. Its heritage shows up in many ways, including integration with the business-focused IBM Smart Cloud. (Other integrations are in the works.) Regulated enterprises and governments form the bulk of Silanis’ client base. The company’s Java and .NET SDKs appeal to these customers, although not as often to smaller companies and independent developers.

Just a glance at the API documentation and you can tell that Silanis’ approach is different. The calls are oriented around working with packages, the basic unit of a transaction for e-Sign Live. A package contains all the elements of a signing transaction: documents, approvals, users with roles, workflow routes and more. The actual process of applying all this is called an “e-Sign Ceremony.”

If you plan to write Java or .NET code, Silanis e-Sign is a very friendly environment. The SDKs are fairly extensive and give well-designed access to higher-level features than are found in the base API calls. Silanis says that other SDKs are in the works. If you’re not writing Java or .NET code, e-Sign Live is completely unhelpful. It’s theoretically possible to program the API directly (using REST and JSON) from some other language, but you’d be much better off just taking your business elsewhere.

In addition, the documentation for the API is scant. In other products, much of the division of functions is accomplished by creating separate APIs. In e-Sign Live, this is accomplished by manipulating the large and complex JSON schema.

Another interesting example of the difference in the Silanis approach is that it tends not to incorporate functions that are in the other APIs. For example, each package has a package ID (a GUID) that the program must supply to E-Sign in order to access and manage that package, but there is no function for enumerating packages. That must be done by the outside application (or the Silanis user interface for the standard business version of e-Sign). Other APIs typically have a means of enumerating documents associated with the account or user.

All of this supports the conclusion that Silanis e-Sign Live is not usable without a higher-level language SDK; even with that, it is lacking in many ways compared to other products. Because of Silanis’ background with heavily regulated businesses, e-Sign has a good set of APIs and SDK interfaces for documents, metadata and audit trails. But the documentation and other facilities are written only for Java and .NET programmers.

Silanis provides two kinds of trial accounts: a business user trial, which gives access to its stand-alone user interface and does not include API access; and a sandbox account for developers. The developer sandbox accounts do not expire and has no limit on the number of documents a company can create, but all documents put into the system get watermarked by Silanis. This is a very developer-friendly arrangement, allowing testing and analysis of the system without any time rush.

Silanis is weak when it comes to developer community. There are no forums or other means for developers to interact, although the company says it is working on it. The Developer Portal has a “Forums” link which says “Coming soon!”


Products Not Tested Arx CoSign

ARX CoSign (http://www.arx.com/) is an enterprise tool for using digital signatures to authenticate users and other objects in the system. CoSign also has an e-signature feature, which it refers to as “graphical signatures,” but, for the most part, the product associates digital signatures to documents so that others, inside or outside the organization, can verify the authenticity and integrity of documents. (For more on the distinction between e-signatures and digital signatures, read the section that appears earlier in this paper.)

In many ways, the use case for digital signatures as CoSign provides them is the same as that of e-signatures. But CoSign is a far more complex product that does much more than any of the e-signature-only products.

If all you are looking for is e-signatures, then CoSign is not for you. However, if your organization is large enough and needs security standards that are more rigorous than those found in the products analyzed in this paper, CoSign is a good candidate. For example, CoSign offers both a cloud and on-premise version of its platform. Companies in heavily regulated industries—such as health care, finance and transportation—are likely to have these requirements.

We did not include this product in our report because e-signing represents only a fraction of its functionality.

AssureSign

AssureSign (http://www.assuresign.com/) has had a SOAP/XML API for e-signing for many years. Until fairly recently, the company restricted access to the API to licensed partners. Now, however, the API is open. We intended to include AssureSign in this comparison, but we had to remove the product late in the process because we had some difficulty getting the service to work and could not resolve the issues before press time.

Universign

Universign (https://www.universign.eu/en/) focuses on ease of use, simplicity and legal compliance for the European market. Its API (https://www.universign.eu/en/api/electronic-signature/) is based on XML-RPC, a technology that was the inspiration for SOAP. This makes it much simpler than SOAP, but it will perhaps be unfamiliar to many developers. We decided not to include it at the suggestion of Universign and because its European focus would make comparison difficult.

API Feature SetThe features of e-signature providers are segmented into eight categories:

• Signing Options: Define and handle signing locations and signing process• Transaction Verification: Access status updates, view audit logs and verify transaction steps• Template Support: Apply pre-defined templates to documents in order to facilitate document

sending• Document Support & Functionality: Create and send documents• Form & Form Field Support: create dynamic documents to define the transaction workflow• Workflow Support: Define the signing process in a way that best fits the parameters of the

transaction• Security & Fraud Prevention: Secure transaction documents and authenticate document recipients• API and Data Types: Does the product support REST and/or SOAP, JSON and/or XML?


The charts in this section cover only features supported through the API. Some of the products may support features in this chart, but only through their user interface.

Signing Options

Number of signing modes

Sender can choose signing option Custom Options

Adobe Echo Sign 4 4 Specify signing page/email language

Barracuda SignNow 4 In person, freeform, embedded signing, email invitation

DocuSign 4 4 Language of signing page + emails can now be specified via the API. DocuSign now allows users to sign with a digital certificate (SAFE-BioPharma, DocuSign Express). Branding of signing and sending experiences is customizable via the APIs, leveraging branding capability.

HelloSign 2 Three signature location options

RightSignature 1 Embedded signing in client interface; signer sequencing to set specific signing order

Sertifi eSignature 4 4 eSign (type signature, biometric touch), paper (print, sign, fax), in-person, in-session (integrated in customers portal), multiple language support

Silanis e-Sign Live 3 3 modes: Click-to-Initial, Click-to-Sign, Scripted Signature. eSignLive account holders may store captured signatures and other associated files for one click application to future signed documents.

Several of the products provide a good selection of methods and locations for signing. All support the obvious electronic signature —the whole point of this market. Many support some form of paper signature. Other options uploaded signature images, digital signatures, required in-person signature and specification of different locations for the signature. RightSignature does support paper/fax signing, but it is an account setting and not controllable through the API.


Transaction Verification

Adobe Echo Sign

Barracuda SignNow

DocuSign HelloSign RightSignature Sertifi eSignature

Silanis e-Sign Live

Receive event-driven status updates

4 4 4 4 4 4 4

Event failure notification

4 4 4 4 4 4

Send remind/expire/no receive audit log of transactions

4 4 4 4 4 4

Receive audit log of transaction

4 4* 4 4 4 4 4

Access certificate of completion and authoritative copy

4* 4 4 4 4 4

* Barracuda says it has this feature but that it is undocumented. We did not verify this claim.

You can see that there are a few gaps in this chart—mostly attributable to SignNow. The absence of failure notification and remind/expire notices is a pretty serious problem, particularly when competing products perform better in those areas. RightSignature notes that the product can be configured to provide email notifications to the API key holder if the callback fails.

Template Support

Adobe Echo Sign

Barracuda SignNow


Silanis e-Sign Live

Apply template to documents

4 4 4 4 4 4 4

Templates are frequently used documents that are customized to a particular signing. Certain contracts that are sent out frequently but differ just in terms of, say, the name of a party and dates are good candidates for templating. Adobe did not claim template support, but its Library Documents—which are, in effect, PDFs—serve many of the same functions. The EchoSign API cannot create Library Documents, but it can use them. The level of support for templates differs among the products. DocuSign, Sertifi and, to a lesser extent, Silanis, have layout support and field creation/editing support for templates.


Document Support and Functionality

Adobe Echo Sign

Barracuda SignNow


Silanis e-Sign Live

Send document to multiple recipients

4 4 4 4 4 4 4

Create/Send batches

4 4* 4 4 4 4

Define document visibility

4 4* 4 4 4 4 4

Submit complete and partially-finished batches for delivery

4* 4 4 4

Void batches 4 4* 4 4 4 4 4Edit recipient info or transfer ownership of an existing batch

4 4 4

* Barracuda says it has this feature but that it is undocumented. We did not verify this claim.

All of the products can send a document to multiple recipients and send batches of multiple documents. In a sense, this is a minor convenience because your software can always just loop through a list of documents, calling the APIs for each. But there is certainly value in being able to do just one API call.

The level of support differs among products. With the exception of Adobe EchoSign, all of the products we tested can specify the signing order for signers. Some can specify that certain signers are required while others are optional. Sertifi claims to have the ability to specify as many as 10 sequential levels of signing with parallel signing orders at each level.

Things get more complicated with batches of documents. EchoSign, SignNow and HelloSign can send documents in batches; DocuSign and RightSignature can send templates and forms in batches (RightSignature calls them “packages”).

DocuSign and Sertifi are the clear leaders in the area of document visibility. They can specify which users can see which documents. DocuSign supports Accessibility Reading Zones, which permit screen reading applications to read instructions, envelope documents and DocuSign tags.

SignNow, DocuSign and Sertifi allow software to submit complete and partially finished batches for delivery.

Only DocuSign and Sertifi allow programs to edit the participants in an already-created batch and transfer or modify ownership.


Form & Field Support Form Support

Adobe Echo Sign

Barracuda SignNow


Silanis e-Sign Live

Create forms, distribute forms via multiple protocols

4 4

Field Support

Adobe Echo Sign

Barracuda SignNow


Silanis e-Sign Live

Create/Place form fields

4 4 4

Multiple form field types

4 4 4

Define field locations and field operations

4 4 4

Assign specific signing tasks or data fields to specific individuals

4 4 4

Most simpler applications will use Acrobat or some other product for form design and modification, but Barracuda SignNow, DocuSign and Silanis e-Sign Live all allow users to manipulate forms in their system directly.

DocuSign can use free form text fields or date, company, title, radio, check and drop-downs. Barracuda supports signatures, test fields, initials, checkboxes and enumerations. Silanis claims support for boolean, text field and pick list fields, and in its documentation we see dates and check boxes, but it’s difficult to tell for sure what is supported. Silanis is not designed for this level of control at the API level, but rather through its Java and .NET SDKs.


Workflow Support

Adobe Echo Sign

Barracuda SignNow


Sertifi eSignature

Silanis e-Sign Live

Routing type for signatures

Serial Serial Serial, parallel and combination

Serial, parallel and combination

Serial Serial, parallel and combination

Serial

Assign agent (3rd party management) or editor roles for recipient

4 4 4 4

Correct/reassign workflow for batches already submitted

4 4 4

Workflow control is a core feature of these products, and all have at least minimal support for it through their APIs. Minimal is all Adobe and Barracuda claim. DocuSign and Sertifi are the leaders here. Both, along with HelloSign, support both serial and parallel signing and a combination of both. Both DocuSign and Sertifi also allow the designation of a third-party agent role (what Sertifi calls a “Power Admin”). RightSignature and Silanis also support this feature. DocuSign, Sertifi and Silanis support a program to change the workflow of an already submitted batch.

With respect to correcting/reassigning workflow for already-submitted batches, RightSignature says that to maintain legal audit logs, the document and designated recipients cannot be edited after the document has been sent. However, it is possible to easily resend documents to new recipients with a duplicated document overlay. The company calls this its Import Overlay feature.


Security & Fraud Protection

Adobe Echo Sign

Barracuda SignNow


Sertifi eSignature

Silanis e-Sign Live

Number of methods of recipient authentication

3 1 8 2 3 5 4

Password protection for documents

4 4 4 4 4

Public key infrastructure (PKI) digital certificates to seal exported documents

4 4 4

Define authentication requirements for signing/accessing batches

4 4 4 4

E-signatures aren’t an inherently secure system. When you electronically submit a document for signature to a recipient, it is important to be able to authenticate the recipient.

In a sense, when the system sends out an e-signature request to an email address, it is inherently authenticated as going to a person with access to that email account. That’s not much, but we’ll count it as one method here.

Adobe has three methods for authentication, including email: Through a partnership with LexisNexis, EchoSign programs can be programmed to require knowledge-based authentication through a series of customized, non-trivial questions from the recipient’s past. Recipients can also sign with their Facebook, LinkedIn or Google accounts, and EchoSign will automatically capture their picture and a URL link for their public web identity. EchoSign also supports password-based encryption of documents.

DocuSign blows away the field with eight methods: email; a special shared access code; digital certificates; a code sent through SMS; phone authentication in which the recipient must call a number and enter their name and a special code; third-party authentication (Google, Salesforce, Yahoo or Microsoft); knowledge-based authentication (recipients are asked a series of credit-check-like questions); and geolocation capture.

In addition to email, HelloSign allows a signer PIN that needs to be entered, similar to DocuSign’s access code.

Sertifi has a very respectable selection: email; a folder-based password (this is a special password particular to Sertifi’s architecture); users can be required to create and log in with a Sertifi account; knowledge-based authentication; and a phone verification similar to DocuSign’s.

RightSignature supports email, a custom password, and (uniquely, we believe) a webcam photo to be returned with the signature.

Silanis supports email; a shared secret (access code); SMS code; and third-party authentication.

SignNow only supports email.


There are other techniques to strengthen security: EchoSign, DocuSign, HelloSign, RightSignature and Sertifi allow password protection of documents themselves.

DocuSign, Sertifi and Silanis support digital certificates to “seal” documents. Sertifi requires an additional module and fee for this feature, whereas Silanis says that all its documents are sealed in this way.

Finally, DocuSign, Sertifi and Silanis all support special authentication requirements for signing or accessing batches.

API Types

Adobe Echo Sign

Barracuda SignNow


Sertifi eSignature

Silanis e-Sign Live

REST 4 4 4 4 4 4

SOAP 4 4 4

Both EchoSign and DocuSign started out with SOAP APIs and more recently added REST. Sertifi supports only SOAP now, but says it will soon release a REST API. The other products support only REST.

Data Types

Adobe Echo Sign

Barracuda SignNow


Sertifi eSignature

Silanis e-Sign Live

Request body formats supported

JSON JSON JSON, XML JSONX

JSON XML XML JSON

Response body formats supported

JSON (Some PDF,

some raw data)

JSON JSON, XML JSON JSON, XML XML JSON (Some

ZIP, PDF)

Both XML and JSON have their fans, but it’s clear that JSON is on the rise. Other than Sertifi, the products all support JSON in at least some context, and it would seem that RightSignature will eventually support JSON for request data. As SOAP is an XML protocol by definition, Sertifi supports it and only it. Sertifi says that when its REST API comes out it will support JSON.


ConclusionA lot has changed since our last look at e-signing APIs, three years ago: The market is much bigger, with many more products to choose from. But one thing has not changed: DocuSign is still the clear leader.

Our evaluation showed that DocuSign has the greatest breadth of features available under the API, the best developer tools and the best code samples and documentation. However, for some users, the API is so large that it may be intimidating and difficult to get off the ground. With that said, one man’s complicated is another man’s powerful and comprehensive.

At the other end of the complexity spectrum is HelloSign. Both the product and the API are simple and easy to use. The feature analysis chart shows at a glance that HelloSign doesn’t have anywhere near the capabilities of DocuSign, but some users have simple needs—and/or an aversion to complexity—that will be satisfied by HelloSign. If you need to write a quick program that incorporates digital signing and you don’t have any expectations of growing it, HelloSign may be the right choice.

Sertifi eSignature supports only SOAP and XML for now, which will limit its appeal among some users, but SOAP programmers should feel at ease with the platform. It has excellent documentation and a very capable API, if not quite as many features as DocuSign. Of course, DocuSign also provides support for SOAP/XML, even if the company says there is little interest in SOAP among its current customers. If you want to write SOAP code for e-signing, both DocuSign and Sertifi are good choices.

The other four products—Adobe EchoSign, Barracuda SignNow, RightSignature and Silanis e-Sign Live—were disappointing to varying degrees in our evaluation. EchoSign may be the most disappointing, as Adobe seems to be letting the product, or at least the API in the product, stagnate.

RightSignature’s, Silanis’ and Barracuda’s products were all challenging to work with, had API documentation that ranged from bad to worse, and offered minimal sample code. SignNow is least ready for prime time.

The good news is that developers have several good options—with DocuSign leading the pack—for automating the most old-world of processes, leading to great leaps in productivity.

DISCLOSURE: ProgrammableWeb was retained by DocuSign to develop this report. However, one of the conditions under which ProgrammableWeb accepts such

custom research work is that the reports’ underwriters can, in no way, influence the methodologies used in evaluating the various players or the final

outcome of the report. In fact, the only part of the outcome that DocuSign influenced was the inclusion of its API in the comparison. Beyond that,

the testers, writers and editors who had a hand in this report’s production received no guidance, instructions or influence—directly or indirectly—from

DocuSign. Questions about this report or ProgrammableWeb’s custom research program should be directed to [email protected].


ProgrammableWeb gets you the latest on what’s new and interesting with mashups, Web 2.0

APIs, and the Web as Platform. It’s a directory, a news source, a reference guide, a community.

Visit us at programmableweb.com.

programmableweb's esignature api research report

Technology