Discovering the valid API access point

Before working with Sign API, create a free developer account to access the API, test your document exchange and execution, and test the emailing feature.

Adobe distributes Acrobat Sign API around the globe in many deployment units called “shards.” Each shard serves a customer’s account, such as NA1, NA2, NA3, EU1, JP1, AU1, IN1, and others. The shard names correspond to geographic locations. These shards compose the base URI (access points) of the API endpoints.

To access Sign API, you must first discover the correct access point for your account, which can be api.na1.adobesign.com, api.na4.adobesign.com, api.eu1.adobesign.com, or others, depending on your location.

  GET /api/rest/v6/baseUris HTTP/1.1
  Host: https://api.adobesign.com
  Authorization: Bearer {YOUR-INTEGRATION-KEY-HERE}
  Accept: application/json

  Response Body (example):

  {
    "apiAccessPoint": "https://api.na4.adobesign.com/",
    "webAccessPoint": "https://secure.na4.adobesign.com/"
  }

In the above example, is a response with the value as the access point.

IMPORTANT
In this case, all subsequent requests you make to Sign API must use that access point. If you use an access point that doesn’t serve your region, you get an error.

Uploading a transient document

Adobe Sign enables you to create different flows that prepare documents for signatures or data collection. Regardless of your application’s flow, you must first upload a document, which remains available for only seven days. The subsequent API calls must then reference this temporary document.

The document uploads using a POST request to the /transientDocuments endpoint. The multipart request consists of the file name, a file stream, and the document file’s MIME (media) type. The endpoint response contains an ID that identifies the document.

Additionally, your application can specify a callback URL for Acrobat Sign to ping, notifying the app when the signature process is complete.

  POST /api/rest/v6/transientDocuments HTTP/1.1
  Host: {YOUR-API-ACCESS-POINT}
  Authorization: Bearer {YOUR-INTEGRATION-KEY-HERE}
  x-api-user: email:your-api-user@your-domain.com
  Content-Type: multipart/form-data
  File-Name: "Insurance Form.pdf"
  File: "[path]\Insurance Form.pdf"
  Accept: application/json

  Response Body (example):

  {
     "transientDocumentId": "3AAA...BRZuM"
  }

Creating a Web Form

Web Forms (previously known as signing widgets) are hosted documents that anyone who has access can sign. Examples of Web Forms include signup sheets, waivers, and other documents that many people access and sign online.

To create a new Web Form using the Sign API, you must first upload a transient document. The POST request to the /widgets endpoint uses the returned transientDocumentId .

In this example, the Web Form is ACTIVE, but you can create it in one of three different states:

  • DRAFT — to incrementally build the Web Form

  • AUTHORING — to add or edit form fields in the Web Form

  • ACTIVE — to immediately host the Web Form

The information on the form’s participants must also be defined. The memberInfos property contains data on the participants, such as email. Currently, this set does not support more than one member. But, since the email of the Web Form signer is unknown at the time of Web Form creation, the email should be left empty, like in the following example. The role property defines the role assumed by the members in memberInfos (such as the SIGNER and APPROVER).

  POST /api/rest/v6/widgets HTTP/1.1
  Host: {YOUR-API-ACCESS-POINT}
  Authorization: Bearer {YOUR-INTEGRATION-KEY-HERE}
  x-api-user: email:your-api-user@your-domain.com
  Content-Type: application/json

  Request Body:

  {
    "fileInfos": [
      {
      "transientDocumentId": "YOUR-TRANSIENT-DOCUMENT-ID"
      }
     ],
    "name": "Insurance Form",
      "widgetParticipantSetInfo": {
          "memberInfos": [{
              "email": ""
          }],
      "role": "SIGNER"
      },
      "state": "ACTIVE"
  }

  Response Body (example):

  {
     "id": "CBJ...PXoK2o"
  }

You can create a Web Form as DRAFT or AUTHORING, then change its state as the form passes through your application pipeline. To change a Web Form state, refer to the PUT /widgets/{widgetId}/state endpoint.

Reading the Web Form hosting URL

The next step is to discover the URL hosting the Web Form. The /widgets endpoint retrieves a list of Web Form data, including the hosted URL of the Web Form that you forward to your users, to collect signatures and other form data.

This endpoint returns a list, so you can locate the specific form by its id in the userWidgetList before getting the URL hosting the Web Form:

  GET /api/rest/v6/widgets HTTP/1.1
  Host: {YOUR-API-ACCESS-POINT}
  Authorization: Bearer {YOUR-INTEGRATION-KEY-HERE}
  Accept: application/json

  Response Body:

  {
    "userWidgetList": [
      {
        "id": "CBJCHB...FGf",
        "name": "Insurance Form",
        "groupId": "CBJCHB...W86",
        "javascript": "<script type='text/javascript' ...
        "modifiedDate": "2021-03-13T15:52:41Z",
        "status": "ACTIVE",
        "Url":
        "https://secure.na4.adobesign.com/public/esignWidget?wid=CBFCIB...Rag*",
        "hidden": false
      },
      {
        "id": "CBJCHB...I8_",
        "name": "Insurance Form",
        "groupId": "CBJCHBCAABAAyhgaehdJ9GTzvNRchxQEGH_H1ya0xW86",
        "javascript": "<script type='text/javascript' language='JavaScript'
        src='https://sec
        "modifiedDate": "2021-03-13T02:47:32Z",
        "status": "ACTIVE",
        "Url":
        "https://secure.na4.adobesign.com/public/esignWidget?wid=CBFCIB...AAB",
        "hidden": false
      },
      {
        "id": "CBJCHB...Wmc",

Managing your Web Form

This form is a PDF document for users to fill in. However, you still need to tell the form’s editor which fields the users must fill in and where they are located within the document:

Screenshot of insurance form with a few fields

The document above doesn’t show the fields — yet. They are added while defining which fields collect the signer’s information, as well as their size and position.

Now, go to the Web Forms tab on the “Your agreements” page and find the form you created.

Screenshot of the Acrobat Sign Manage tab

Screenshot of the Acrobat Sign Manage tab with Web Forms selected

Click Edit to open the document editing page. The available predefined fields are on the right panel.

Screenshot of the Acrobat Sign form authoring environment

The editor enables you to drag and drop text and signature fields. After you add all the necessary fields, you can resize and align them to polish your form. Finally, click Save to create the form.

Screenshot of the Acrobat Sign form authoring environment with form fields added

Sending a Web Form for signing

After finishing the Web Form, you must submit it so users can fill and sign it. Once you save the form, you can view and copy the URL and embedded code.

Copy Web Form URL: use this URL to send users to a hosted version of this agreement for review and signature. For example:

https://secure.na4.adobesign.com/public/esignWidget?wid=CBFCIBAA3…babw*

Copy Web Form embed code: add the agreement to your website by copying this code and pasting it into your HTML.

For example:

<iframe
src="https://secure.na4.adobesign.com/public/esignWidget?wid=CBFC
...yx8*&hosted=false" width="100%" height="100%" frameborder="0"
style="border: 0;
overflow: hidden; min-height: 500px; min-width: 600px;"></iframe>

Screenshot of final Web Form

When your users access the hosted version of your form, they review the transient document first uploaded with the fields positioned as specified.

Screenshot of final Web Form

The user then fills in the fields and signs the form.

Screenshot of user selecting Signature field

Next, your user signs the document with a previously stored signature, or with a new one.

Screenshot of signing experience

Screenshot of signature

When the user clicks Apply, Adobe instructs them to open their email and confirm the signature. The signature remains pending until the confirmation arrives.

Screenshot of Just one more step

This authentication adds multiple-factor authentication and strengthens signing process security.

Screenshot of confirmation message

Screenshot of completion message