Learn how to use Adobe Sign APIs to embed e-signature and document experiences into your web platforms and content and document management systems. There are four parts to this hands-on tutorial outlined in the links below:
In part 1, you’ll learn how to get started with everything you need for parts 2–4. Let’s begin with getting API credentials.
In part 2, you’ll explore the low/no-code option when using webforms. It’s always a good idea to see if you can avoid writing code at first.
Access Adobe Sign with your developer account.
Click Publish a web form on the home page.
Create your agreement.
Embed your agreement on a flat HTML page.
Experiment with dynamically adding query parameters.
In part 3, you’ll dynamically create agreements.
First, you’ll need to establish access. With Adobe Sign, there are two ways to connect via API. OAuth Tokens & Integration Keys. Unless you have a very specific reason to use OAuth with your application, you will want to explore Integration Keys first.
Select Integration Key on the API Information menu under the Account tab in Adobe Sign.
Now that you have access and can interact with the API, see what you can do with the API.
Navigate to the Adobe Sign REST API Version 6 Methods.
Use the token as a “bearer” value.
To send your first agreement it’s best to understand how to use the API.
JSON-based request calls have a “Model” and “Minimal Model Schema” option. This gives specs and a minimum payload set.
After sending an agreement for the first time, you’re ready to add the logic. It’s always a good idea to establish some helpers to minimize repetition. Here are some examples:
Be aware of where Transient docs land within the grand scheme of the Sign ecosystem.
Transient -> Agreement
Transient -> Template -> Agreement
Transient -> Widget -> Agreement
This example uses a template as our document source. This is usually the best route, unless you have a solid reason to dynamically generate documents for signature (e.g., legacy code or document generation).
The code is fairly straightforward; it uses a library document (template) for the document source. The first and second signers are dynamically assigned. The
IN_PROCESS state means that the document is being sent immediately. Also,
mergeFieldInfo is leveraged to dynamically fill fields.
In many scenarios, you may want to allow the triggering participant to immediately sign an agreement. This is useful for customer-facing applications and kiosks.
If you don’t want the first sending email to trigger, an easy way is to manage the behavior is with a modification to the API call.
Here’s how to control the post-signing redirect:
After updating the agreement creation process, the final step is generating the signing URL. This call is also pretty straightforward and generates a URL that a signer may use to access their part of the signing process.
Note that the agreement creation call is technically asynchronous. This means a ‘POST’ agreement call can be made, but the agreement isn’t ready yet. The best practice is to establish a retry loop. Use a retry or whatever is the best practice for your environment.
When everything is put together, the solution is pretty straightforward. You’re making an agreement and then generating a signing URL for the signer to click on and begin the signing ritual.
With the initial creation
Or add one in-flight