Create embedded e-signature and document experiences

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:

What you'll need Part 2: Low/No Code — the power of web forms Part 3: Send agreement with a form, merge data Part 4: Embed signing experience, redirects, and more

Part 1: What you’ll need

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.

Part 2: Low/No Code — the power of web forms

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.

  1. Access Adobe Sign with your developer account.

  2. Click Publish a web form on the home page.

    Screenshot Adobe Sign home page

  3. Create your agreement.

    Screenshot of how to create a web form

  4. Embed your agreement on a flat HTML page.

  5. Experiment with dynamically adding query parameters.

    Screenshot of adding query parameters

Part 3: Send agreement with a form and merge data

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.

  1. Select Integration Key on the API Information menu under the Account tab in Adobe Sign.

    Screenshot of where to find the integration key

Now that you have access and can interact with the API, see what you can do with the API.

  1. Navigate to the Adobe Sign REST API Version 6 Methods.

    Screenshot of navigating Adobe Sign REST API Version 6 Methods

  2. Use the token as a “bearer” value.

    Screenshot of bearer value

To send your first agreement it’s best to understand how to use the API.

  1. Create a Transient Doc and send it.
NOTE

JSON-based request calls have a “Model” and “Minimal Model Schema” option. This gives specs and a minimum payload set.

Screenshot of creating a Transient Doc

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:

Validation

Screenshot of validation logic

Headers/Auth

Screenshot of headers/auth logic

Base URI

Screenshot of Base URI logic

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.

Screenshot of code to dynamically add signatures

Part 4: Embed signing experience, redirects, and more

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.

Screenshot of code to not trigger sending email

Here’s how to control the post-signing redirect:

Screenshot of code to control 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.

Screenshot of code to generate a signer URL

NOTE

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.

Screenshot saying it's best practice to establish a retry loop

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.

Additional topics

Additional Resources

http://bit.ly/Summit21-T126

Includes:

  • Adobe Sign Developer Account
  • Adobe Sign API Docs
  • Sample Code
  • Visual Studio Code
  • Python

On this page