Connected fields extension contract reference
The connected fields extension enables you to verify user-entered values in eSignature envelopes against a system of record. The verification result and message from the external system, as well as suggested autofill values, are displayed in the signing UI.
You can include this extension when you register an extension app. If you register the extension app using a form, select the Connected Fields extension in the form-based UI, as shown in this figure:

If you register the extension app using an app manifest file, set the extensions.template value in your app manifest to ConnectedFields.Version1.ConnectedFields.
This extension has three actions. The action names you specify when you register an extension app depend on whether you register the app using a form or using an app manifest file. The app manifest file values listed here appear in the actions.template property.
For details about what each action does and when it is invoked, see Connected fields actions. The connected fields extension uses the data IO extension’s Get Type Names and Get Type Definitions action contracts because the contract details are identical.
You provide the details required for action execution when you register an extension app. See Update extension and action settings for information about defining actions using the form-based registration process. See Action schema for information about action properties in the app manifest file.
Action contracts
Get Type Names (DataIO.Version6.GetTypeNames)
This action calls the external system of record to retrieve the names of the supported types. These types represent the data objects (or database table names) in your system of record. In Concerto nomenclature, these are referred to as concepts.
Note: The names of the types returned by this action will be used as input for the Get Type Definitions (DataIO.Version6.GetTypeDefinitions) action.
Get Type Names is the label for this action that appears when you register an extension app using a form. If you register your extension app using an app manifest file, the actions.template property value for this action is DataIO.Version6.GetTypeNames. The connected fields extension uses the data IO extension’s Get Type Names action contract because the contract details are identical.
HTTP method
This action initiates a POST request to the external API service.
Request
The input is an empty JSON object. No data is specified because the external system returns any types that are available for data verification, as indicated by the VerifiableType decorator.
Response
Get Type Definitions (DataIO.Version6.GetTypeDefinitions)
Type definitions are based on the Concerto data modeling language. In Concerto nomenclature, types are referred to as concepts. Given a list of types, the external system must return a list of Concerto declarations representing the properties of each type. Your app proxy should initially fetch the schemas associated with these types and then convert them to Concerto’s metamodel JSON format
. This enables Docusign to interpret your chosen system’s types consistently.
You can use Concerto’s CLI or JavaScript API to convert your models.
Get Type Definitions is the label for this action that appears when you register an extension app using a form. If you register your extension app using an app manifest file, the actions.template property value for this action is DataIO.Version6.GetTypeDefinitions. The connected fields extension uses the data IO extension’s Get Type Definitions action contract because the contract details are identical.
HTTP method
This action initiates a POST request to the external API service.
The following example request and response reflect an external system of record with an Account type. The Account type includes:
The TypeOfAccount enum has the following values:
The EmailAddress type is defined as:
The OwnerName type is defined as:
Request
Response
Verification decorators
The Get Type Definitions response must include decorators that identify concepts that are available for verification. The decorators are:
-
VerifiableType: Apply this decorator to all concepts in the response whose properties should be available for verification. Docusign ignores any concepts in the response that are not marked with this decorator.If a concept includes this decorator, the eSignature Add Fields view will render all properties under the concept as connected fields that can be added to documents for custom data verification. While object properties are supported for verification, relationship properties are not.
Note: Only concept declarations can include the
VerifiableTypedecorator. Do not apply this decorator to enum declarations. To define an enum as verifiable, include the enum as an object property within a concept declaration that has theVerifiableTypedecorator. See the response above for an example, and note the definition of thetypeOfAccountobject property, which references an enum, within theAccountconcept declaration.In the current release, Docusign does not support marking individual properties as verifiable. If you do not want every property in a concept to be verifiable, then include only verifiable properties in the Get Type Definitions response. In addition, Docusign recommends that the response only include concepts that should be available for verification.
-
IsRequiredForVerifyingType: Apply this decorator to properties that, when rendered as envelope fields, must be populated before Docusign sends a verification request to the external system. This decorator can be applied to properties in concepts marked with theVerifiableTypedecorator.Note: To make a property optional, you must include an
isOptionalproperty set totruein the Concerto definition. This is because Docusign treats a property as required by default if the Concerto definition does not include anisOptionalproperty set totrue, even if theIsRequiredForVerifyingTypedecorator is omitted. However, for required properties, Docusign recommends using theIsRequiredForVerifyingTypedecorator to reduce ambiguity.In the Add Fields view, when an envelope or template preparer drags any required connected field to the document, all required connected fields under the same concept will also be inserted into the document as a group.
Optional connected fields under the same concept can be added to the document as part of the same group. If an optional connected field is added to a document without also including required connected fields, verification will fail when envelope recipients populate the optional field.
When creating envelopes programmatically via the Connected Fields API, only required connected fields can be included. The TabInfo:GetConnectedFieldsTabGroups response does not return optional connected fields.
If the Get Type Definitions response includes verification decorators as shown in the example above, the eSignature Add Fields view will display these connected fields:

When an envelope or template preparer drags any of the required fields to the document, all of the other required fields will be inserted as well:

The preparer can rearrange the fields as needed for the document layout.
GetTypeDefinitionError
Verify (ConnectedFields.Version1.Verify)
The Verify action is executed when an eSignature envelope recipient has populated all required connected fields in an envelope, or when the recipient modifies any of those values. The request to the external system includes the user-entered values, and the external system can apply any required business logic to verify them. The response must include a verification result and a success or failure message. Optionally, the response can include suggested values to autofill in the signing UI.
Verify is the label for this action that appears when you register an extension app using a form. If you register your extension app using an app manifest file, the actions.template property value for this action is ConnectedFields.Version1.Verify.
HTTP method
This action initiates a POST request to the external API service.
Request
Response
Example response 1
Example response 2
Example response 3
This response indicates that verification succeeded and includes a verifyResponseMessage, which is displayed in the signing UI.
Note: Any response values that are not displayed in the signing UI can be retrieved by running a Verify action extension test on the Developer Console Testing page.
Error handling
If a connected fields action results in an error that prevents the request from being processed, the external system should return an HTTP error code 400, 404, or 500 along with a message describing the error.
Do not return one of these errors if the verification logic was executed and identified one or more user-entered values as invalid. In that case, return a Verify response with the verified property set to false, and supply appropriate values for the verifyResponseMessage and verifyFailureReason properties.
Example error responses:
This error structure applies to all actions. Developers are responsible for providing a code and message for each error.
Retry logic
If Docusign receives a 500 Internal Server Error in response to an action request, it implements retries as follows:
- Docusign resends the request up to three times.
- For a Verify request retry, the
idempotencyKeyis the same as in the original request, so that the external system can identify it as a resubmitted request. - After the third retry fails, Docusign considers the request to have failed.
- If Docusign does not receive a response to a request within 15 seconds, up to three retries are launched before the request is considered a failure.
Next steps
- Get an overview of the connected fields extension and how it can be used.
- Find out more about the data model.
- Explore the options for testing a connected fields extension app.