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!
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!
