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 RightSignature
Barracuda SignNow Sertifi eSignature
DocuSign Silanis e-Sign Live
HelloSign
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. XML
As 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 signatures
A 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 integrations
It 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 APIs
In 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 them
We 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 us
We 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 RESTTry 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 Set
The 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
eSignature
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
eSignature
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 4
Edit 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
eSignature
Silanis
e-Sign
Live
Create forms,
distribute
forms via
multiple
protocols
4 4
Field Support
Adobe
Echo Sign
Barracuda
SignNow
eSignature
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
Signature
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
Signature
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
Signature
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
Signature
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.

Conclusion
A 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 editor@programmableweb.com.

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

Similaire à ProgrammableWeb's eSignature API Research Report

Similaire à ProgrammableWeb's eSignature API Research Report (20)

Plus de ProgrammableWeb

Plus de ProgrammableWeb (20)

Dernier

Dernier (20)

ProgrammableWeb's eSignature API Research Report