The all new and powerful Adobe eSign REST API v5

We have been pretty busy with making updates to our Adobe eSign REST APIs and am really happy to announce that with the REST API v5, we are almost there. 

As you can also notice, we have also introduced multiple functionality and features which are REST API only like "Try It" functionality, integrated "OAuth Support", custom workflows and pagination in events end-points. 

Here is a complete mapping from our SOAP to REST APIs

SOAP API	REST end-point	Comments
Base URIs API calls starting v5 of REST API must be made on a specific base URL obtained either from the api_access_point returned from OAuth workflow or making a call to the GET /base_uris endpoint Transient Document - REST allows documents to be used for creating agreements, widgets and library documents to be uploaded separately and return ids to be used in respective creation calls
getBaseUris	/base_uris, GET
Document Methods
-NA-	/transientDocuments, POST	Uploads a document and return an id valid for 7 days
sendDocument	/agreements, POST	SenderInfo is represented through x-api-user. Files are specified through /transientDocuments above
sendDocumentInteractive	/agreements, POST	InteractiveOptions can be optionally specified for the Interactive behavior
sendDocumentMegaSign	/megaSigns, POST	MegaSign allows sending the same agreement to multiple recipients and creating a separate instance of agreement for each recipient
createLibraryDocument	/libraryDocuments, POST
createLibraryDocumentInteractive	/libraryDocuments, POST	InteractiveOptions can be optionally specified for the Interactive behavior
sendReminder	/reminders, POST
removeDocument	/agreements/{agrId},  DELETE	Deletes the agreement and removes it from Manage Page
cancelDocument	/agreements/{agrId}/status, PUT	Cancel - Called by sender
rejectDocument	/agreements/{agrId}/status, PUT	Reject - Called by current signer
replaceSigner	- Coming Soon-	Replace - Called by sender. Both the original signer and new one can sign
delegateSigning	- Coming Soon-	Delegate - Called by signer. Both the delegator and delegatee can sign
notifyDocumentVaulted	-NAY-
Status Methods
In SOAP API, getDocumentInfo, getDocuments, getAuditTrail etc work on documentKeys which can be an agreement, widget or library document ids. REST API demarcates these as separate resources (cleaner design and strongly typed) and hence based on the kind of resource you are working on, there is a corresponding /libraryDocuments,  /widgets to these .Eg, /widgets/{widgetId}, GET will getDocumentInfo for widgetId. Similarly for the documents, audit trail etc
getDocumentInfo	/agreements/{agrId}, GET
getDocumentInfosByExternalId	/agreements, GET query = externalId	externalId can be used to map your internal Ids to eSign Ids
getDocuments	/agreements/{agrId}/documents, GET	REST returns a list of document ids that can be provided to the following end-point to get document stream
-NA-	/agreements/{agrId}/documents/{docId}, GET	Returns the raw stream of the file. More efficient/compact than base64
-NA-	/agreements/{agrId}/ combinedDocument, GET	Returns raw stream of combined agreement. Can also request to attach audit trail/supporting docs
getDocumentUrls	/agreements/{agrId}/combinedDocument/ url, GET /agreements/{agrId}/documents/{docId}/ url, GET	Retrieve the URL of the combined document Retrieve the URL of an individual document
getDocumentImageUrls	/agreements/{agrId}/documents/imageUrls, GET /agreements/{agrId}/documents/{docId}/ imageUrls, GET	Retrieve the image URLs of all the visible pages of an agreement Retrieve image URLs of all the visible pages of an agreementÕs document
getSupportingDocuments	/agreements/{agrId}/documents, GET	Can also specify content format
getFormData	/agreements/{agrId}/formData, GET	Returns CSV file stream
getAuditTrail	/agreements/{agrId}/auditTrail, GET
getSigningUrl	/agreements/{agrId}/signingUrls, GET
User Methods
verifyUser	-NA-
searchUserDocuments	/agreements, GET	Provide search string in 'query' parameter
-NA-	Agreement asset below refers to any asset through which an agreement can be created - library document, widget and agreement itself
getDocumentEventsForUser	/search/agreementAssetEvents, POST	Create search query with date range and event type filters. Get searchId, first page results & next page cursor
-NA-	/search/agreementAssetEvents/ {searchId}, GET	Use searchId and pageCursor to get paginated results
getEmbeddedView	/views/agreementAssets, GET	Equivalent to specifying EmbeddedViewTarget= AGREEMENT
	/views/agreementAssetList, GET	EmbeddedViewTarget = AGREEMENT_LIST
	/views/settings, GET	EmbeddedViewTarget = USER_PROFILE/ACCOUNT_SETTINGS
getMyDocuments	/agreements, GET
getUserDocuments	/agreements, GET	Use x-api-user for specifying the user whose agreements are to be retrieved
getMyLibraryDocuments	/libraryDocuments, GET
getLibraryDocumentsForUser	/libraryDocuments, GET	Use x-api-user for specifying the user whose lib documents are to be retrieved
getMyWidgets	/widgets, GET
getWidgetsForUser	/widgets, GET	Use x-api-user for specifying the user whose widgets are to be retrieved
getMegaSignDocument	/megaSigns/{megaSignId}/agreements, GET	Get all child agreement ids of the parent MegaSign
getUsersInAccount	/users, GET
createGroup	/groups, POST
deleteGroup	/groups/{groupId}, DELETE
renameGroup	/groups/{groupId}, PUT
getGroupsInAccount	/groups, GET
getUsersInGroups	/groups/{groupId}/users, GET
moveUsersToGroup	/users/{userId}, PUT	Specify the new groupId in the request
getUserInfo	/users/{userId}, GET
Widget Methods
REST simplifies the various creation and personalization methods of SOAP into two endpoints
createEmbeddedWidget	/widgets, POST
createPersonalEmbeddedWidget	/widgets, POST /widgets/{widgetId}/personalize, PUT	Create and personalize
personalizeEmbeddedWidget	/widgets/{widgetId}/personalize, PUT
createUrlWidget	/widgets, POST
createPersonalUrlWidget	/widgets, POST /widgets/{widgetId}/personalize, PUT	Create and personalize
personalizeUrlWidget	/widgets/{widgetId}/personalize, PUT
disableWidget	/widgets/{widgetId}/status, PUT	Use status value as DISABLE
enableWidget	/widgets/{widgetId}/status, PUT	Use status value as ENABLE

Adobe eSign REST API v4 is live!

We just completed the July release of Adobe Document Cloud eSign services (EchoSign)  and with that introduced a new version of the EchoSign REST API v4. This release is focussed on enabling some key enterprise and SMB scenarios through APIs. Lets take a moment to walk through each of them.


1. Recipient Sets -  Enterprises and SMBs usually have departments and teams to handle a function, for instance, Human Resources, Legal or Purchase. Very often, more than one person in a department has the authority to sign the same agreement in an equivalent manner. In other words, a core use case in multiple businesses is to allow "any one out of N members" of a set of N recipients to sign an agreement and the signing workflow should seamlessly capture this and continue. This facility is now available through REST APIs in Adobe eSign and reflected, for instance, in the recipientSetInfos in /agreements, POST for sending an agreement and participantSetInfos in /agreements/{agreementId}, GET for fetching the participants of an agreement. We consider this concept of a recipient (participant or signer) being a part of a Set so fundamental to eSign workflows that we have  made each recipient by default a set. If your use case requires only one signer per recipient Set, it's easy to do so by just having one member in the recipientSetMemberInfos. Also, for now this is an API only feature and we will consider adding UI for this in future releases.  

2. Custom Workflows -  Most enterprises and SMBs want to benefit from the flexible custom workflows that Adobe eSign supports and have tens and hundreds of them configured in their accounts. Many of them have often requested for these custom workflows to be fetchable and invokable through APIs and their custom applications. So here it comes. We have introduced a new workflows resource for "everything workflows". For starters, you can query this resource to get a list of all the workflows in your account through /workflows, GET. You can also get detailed description of a specific workflow through the /workflows/{workflowId} end-point. Above all, you can invoke a custom workflow i.e send an agreement using a custom workflow through the /workflows/{workflowId}/agreements, POST. Remember to include the new workflow_read Oauth Scope to use these end-points. 

3. Form Fields -  Agreements and widgets almost always tend to have several form fields in them. Very often, enterprise workflows need the flexibility to define and place form fields while an agreement is being created. Adobe eSign currently allows multiple options for proving form fields including text tags, PDF form fields, form field templates and manual authoring. We have taken this flexibility significantly beyond by allowing you to now defined form fields directly within the REST API through a formFields attribute in /agreements, POST. The sub-attributes of this new parameter expose the full functionality of Adobe eSign authoring including form field placement, formatting, validations and conditions so much so that you can build your own custom authoring solution using these.

4. Remove Document - Last but not the least, on popular customer demand we have added the support for the removeDocument SOAP API method in REST through the /agreements/{agreementId}, DELETE method. This method currently behaves exactly like the SOAP API counter part and is expected to be enhanced in future releases.

I believe you are all set to "Try It" out through our Interactive documentation. Go Adobe DC eSign REST v4!

Creating a RESTful API starting from a SOAPish one - Part 1

Now that we understand why APIs are important and how they evolved, let’s go a level deeper with a practical example. In the next several posts, we will cover how EchoSign (now Adobe Document Cloud eSign services) REST APIs were created from scratch maintaining the REST API Design principles while ensuring maximum compatibility with SOAP APIs to provide easy transition to the customers that were using them extensively. Keeping SOAP API as a reference has two benefits. Firstly, if you have an existing SOAP API, this provides a suggested approach on how you can easily transition to a REST API. Secondly it allows us to clearly notice the difference in paradigms between SOAP and REST in a real world example.

Here is high level diagram of the REST API resources in EchoSign and how they are connected

And then straight to the 20,000 feet dive. Following is the first set of the 1<>1 mapping of SOAP API methods (Document and Status) and REST endpoints of EchoSign, the Adobe Document Cloud eSign service. We will talk about these through the blog but many of you have asked for this list before and seeing the end result makes several of us happier

For reference, you can find the latest version of the EchoSign SOAP API here

And the REST counterpart can be checked-out here.

SOAP API method	REST end-point	Comments
Transient Document - REST allows documents to be used for creating agreements, widgets and library documents to be uploaded separately and return ids to be used in respective creation calls
-NA-	/transientDocuments, POST	Uploads a document and return an id valid for 7 days
sendDocument	/agreements, POST	SenderInfo is represented through x-user-id/email. Files are specified through /transientDocuments above
sendDocument Interactive	/agreements, POST	InteractiveOptions can be optionally specified for the Interactive behavior
sendDocumentMegaSign	-NAY-
createLibraryDocument	/libraryDocuments, POST
createLibraryDocument Interactive	/libraryDocuments, POST	InteractiveOptions can be optionally specified for the Interactive behavior
sendReminder	/reminders, POST
removeDocument	-NAY-
cancelDocument	/agreements/{agrId}/status, PUT	Update the status to CANCEL
rejectDocument	-NAY-
replaceSigner	-NAY-
delegateSigning	-NAY-
notifyDocumentVaulted	-NAY-
In SOAP API, getDocumentInfo, getDocuments, getAuditTrail etc work on documentKeys which can be an agreement, widget or library document ids. REST API demarcates these as separate resources (cleaner design) and hence based on the kind of resource you are working on, there is a corresponding /libraryDocuments,  /widgets to these .Eg, /widgets/{widgetId}, GET will getDocumentInfo for widgetId
getDocumentInfo	/agreements/{agrId}, GET
getDocumentInfosBy ExternalId	-NAY-
getDocuments	/agreements/{agrId}/documents, GET	REST returns a list of document ids that can be provided to the following end-point to get document stream
-NA-	/agreements/{agrId}/documents/ {docId}, GET	Returns the raw stream of the file. More efficient/compact than base64
-NA-	/agreements/{agrId}/ combinedDocument, GET	Returns raw stream of combined agreement. Can also request to attach audit trail/supporting docs
getDocumentUrls	-NAY-
getDocumentImageUrls	-NAY-
getSupportingDocuments	/agreements/{agrId}/documents, GET	Can also specify content format
getFormData	/agreements/{agrId}/formData, GET	Returns CSV file stream
getSigningUrl	/agreements/{agrId}/signingUrls, GET

In the next post, we will cover the remaining set of EchoSign SOAP APIs including the User and Widget methods