FlexAPI™ Documentation

Accessing the powerful, secure SIGNiX service is as easy as a few simple API calls. Whether you're automating the certified delivery of a single document to a known signer, having three documents signed by a variety of signers, integrating the extensive SIGNiX remote online notarization capabilities, or even building in aspects of the SIGNiX user experience, branded, into your own portal or application, the SIGNiX FlexAPI provides you with the tools needed to get the job done.

Introduction

This document specifies the business-to-business (B2B) interface for the SIGNiX Business to Business (B2B) interface (aka FlexAPI). This interface allows customer servers to interact directly with the SIGNiX servers to create new transactions, monitor their progress, and download finished documents.

A document sponsor ("Sponsor") makes B2B requests to SIGNiX and receives responses. The requests and responses are formatted as XML and carried over HTTPS on the Internet, so the B2B interface is also referred to as a web service. The operations that can be performed by the web service are also referred to as web methods. For each web method, this document describes the XML structure of the request and of the matching response.

Please note that the element positioning is in the correct order throughout this document. Variations from these specs will lead to error messages. (For example, don't place <Client> before <Sponsor> in the <CustInfo> element).

Items listed as "required" must be included while items listed as "optional" may be excluded from the XML (if it is included, then there may be a required value). Upper and lower case must be observed.

The detailed structure of this interface is specified in an set of XML schema files, which define the service namespace: urn:com:signix:schema:sdddc-1-1

Basic Integration Workflows

Most every workflow imaginable will use one or more of the SIGNiX API calls, but there are many factors to consider depending on how an integrator wants to expose the SIGNiX features.

Simple Document Delivery and Signature - No Embedded UI

When a use case can be met by programmatically sending a pre-tagged document out to a signer, and doesn't require any embedding of the SIGNiX user interface, a simple API call flow can be used. The progression of steps here (and below in other examples) includes push notifications so the integrated application can know when certain transaction milestones have been met.

Description / Steps

1. SubmitDocument transfers all information about the transaction to SIGNiX, including signer info, PDF document(s) and tasks to complete. Integrated application receives a response including a SIGNiX DocumentSetID which will be used in future calls. A push notification ('Send') is sent back to the system indicating the transaction is sent.

2. Email(s) sent to the signer(s) with a link to sign. Signers will click the link, authenticate (optionally) and review and sign the document(s). When each signer is finished, a push notification ('partyComplete') is returned to the integrated application. If all signers have completed their tasks, another push notification is sent ('complete') indicating the integrated application can now proceed to download the document(s) and audit trail.

3. The integrated application sends a DownloadDocument call to SIGNiX, referencing the DocumentSetID provided earlier. PDF documents and audit trail are returned.

4. Upon receiving the documents in the response from SIGNiX, the integrated application sends a ConfirmDownload call to SIGNiX, which allows SIGNiX to move the documents into a proper retention state.

Embedding the SIGNiX 'Wizard' Interface

Often, PDF documents intended for signature do not already have PDF fields / tags associated with the tasks that a signer may need to complete. In this case, an integrated application may choose to expose some of the SIGNiX 'wizard' interface which allows submitters to use a simple drag-and-drop experience to add tasks for various signers on transaction documents and then send them on to signers.

This example may also be used in remote online notarization, where a notary / submitter is manually adding a notary seal / stamp to the document as well as other pertinent information (i.e. online meeting scheduling).

Deeper levels of integration and embedding can be reached by using SIGNiX AJAX API calls.

Description / Steps

1. SubmitDocument transfers all information about the transaction to SIGNiX, including signer info, PDF document(s) and tasks to complete. In this use case not all tasks may be known. In addition, a 'Suspend on Start' parameter is added to the API call letting SIGNiX know to hold off on sending the transaction. Integrated application receives a response including a SIGNiX DocumentSetID which will be used in future calls.

2. Using the DocumentSetID returned by SIGNIX, the integrated application then sends a GetAccessLink - Submitter call to SIGNIX, which returns a short-lived URL which can be used to embed the SIGNiX interface in an iFrame or other browser window.

3. The submitter / user uses the SIGNiX drag-and-drop interface to add tasks (signatures, text fields, etc) to the document(s) and then clicks Send. Alternatively, the integrated application may send a Resume API call to SIGNiX to start the transaction at SIGNiX. A push notification ('Send') is sent back to the system indicating the transaction is sent.

4. Email(s) sent to the signer(s) with a link to sign. Signers will click the link, authenticate (optionally) and review and sign the document(s). When each signer is finished, a push notification ('partyComplete') is returned to the integrated application. If all signers have completed their tasks, another push notification is sent ('complete') indicating the integrated application can now proceed to download the document(s) and audit trail.

5. The integrated application sends a DownloadDocument call to SIGNiX, referencing the DocumentSetID provided earlier. PDF documents and audit trail are returned.

6. Upon receiving the documents in the response from SIGNiX, the integrated application sends a ConfirmDownload call to SIGNiX, which allows SIGNiX to move the documents into a proper retention state.

Embedding the SIGNiX Signing Experience

An integrated application may want to provide a 'portal' experience to a signer and not rely on SIGNiX delivering emails to notify clients of documents needing to be signed. This may be best employed when clients desire to control access to the signing experience based on a specific workflow requirement.

Deeper levels of integration and embedding can be reached by using SIGNiX AJAX API calls.

Description / Steps

2. Using the DocumentSetID returned by SIGNIX, the integrated application then sends a GetAccessLink - Signer call to SIGNIX, which returns a short-lived URL which can be used to embed the SIGNiX signing interface for a particular signer in an iFrame or other browser window.

3. Signers will authenticate (optionally) and review and sign the document(s). When each signer is finished, a push notification ('partyComplete') is returned to the integrated application. Repeated GetAccessLink calls may be used for other signers in the workflow, repeating steps 2 and 3. Once all signers have completed their tasks, another push notification is sent ('complete') indicating the integrated application can now proceed to download the document(s) and audit trail.

4. The integrated application sends a DownloadDocument call to SIGNiX, referencing the DocumentSetID provided earlier. PDF documents and audit trail are returned.

5. Upon receiving the documents in the response from SIGNiX, the integrated application sends a ConfirmDownload call to SIGNiX, which allows SIGNiX to move the documents into a proper retention state.

Embedding Both the SIGNiX 'Wizard' Interface & Signing Experience

There may be some use cases where PDF documents intended for signature do not already have PDF fields / tags associated with the tasks that a signer may need to complete. In this case, an integrated application may choose to expose some of the SIGNiX 'wizard' interface which allows submitters to use a simple drag-and-drop experience to add tasks for various signers on transaction documents and then send them on to signers. In addition, an integrated application may want to provide a 'portal' experience to a signer and not rely on SIGNiX delivering emails to notify clients of documents needing to be signed. This may be best employed when clients desire to control access to the signing experience based on a specific workflow requirement.

Deeper levels of integration and embedding can be reached by using SIGNiX AJAX API calls.

Description / Steps

4. Using the DocumentSetID returned by SIGNIX, the integrated application then sends a GetAccessLink - Signer call to SIGNIX, which returns a short-lived URL which can be used to embed the SIGNiX signing interface for a particular signer in an iFrame or other browser window.

5. Signers will authenticate (optionally) and review and sign the document(s). When each signer is finished, a push notification ('partyComplete') is returned to the integrated application. Repeated GetAccessLink calls may be used for other signers in the workflow, repeating steps 4 and 5. Once all signers have completed their tasks, another push notification is sent ('complete') indicating the integrated application can now proceed to download the document(s) and audit trail.

6. The integrated application sends a DownloadDocument call to SIGNiX, referencing the DocumentSetID provided earlier. PDF documents and audit trail are returned.

7. Upon receiving the documents in the response from SIGNiX, the integrated application sends a ConfirmDownload call to SIGNiX, which allows SIGNiX to move the documents into a proper retention state.

Transport Details

This section describes more details of how B2B requests and responses are formatted and sent between the client and server and gives the URLs for communicating with the web service.

HTTP Request

B2B requests are submitted with HTTP POST where the HTTP request body (MIME content type "application/x-www-form-urlencoded") is formatted as an HTML form submission with the following form parameters:

Name	Value
method	The name of the web method.
request	The XML of the B2B request.

Note that the parameter names, which are case sensitive, must be in lowercase. The name of the web method is always the name of the outermost XML element of the request, with "Rq" removed.

For example, when sending a SubmitDocument request, the name of the outer XML element is "SubmitDocumentRq" and the method parameter should be set to "SubmitDocument".

HTTP Response

The HTTP response body (content type "text/xml") contains the XML of the B2B response.

Normally, the HTTP response has a success status code (such as 200), and the content type is "text/xml". In this case, the client parses the XML response and processes it by examining the StatusCode, StatusDesc, and other elements.

If an unexpected error occurs or if the system is temporarily unavailable (for maintenance, for example), then the response will have one of the following forms:

The HTTP response has an error status code (such as 500). Typically caused by a software error, a network problem, etc.
The HTTP response has a success status code, but the content type is "text/html". Typically occurs when the server is down for maintenance and the URL fails over to a server that responds with a page announcing the server is down for maintenance. To test a similar case, use http://webtest.signix.biz/sdd/b2b/sdddc_ns.jsp as the web service URL. Note that this URL is for HTTP, not HTTPS; the response is an HTML page that says the SIGNiX site requires HTTPS.
The connection cannot be made or times out, and the client gets no response. Typically caused by a network problem at the client site, server site, or between.

Web Service URL

The service is available at the following service endpoint URL:

https://server/sdd/b2b/sdddc_ns.jsp - This endpoint always validates service requests against the schema, and will return schema-valid responses.

The service is available on the following servers:

For demo/test use, server is webtest.signix.biz, and a demo user ID and password are used. This is the server to use for all development and almost all testing. Real documents and real identity information should not be submitted to this server.
For production use, server is www.signix.net, and a real user ID and password are used. This is the server to use for real transactions.

NOTE: Be sure devices that will be accessing SIGNiX for signing or transaction editing (Wizard) have allow-listed the URLs above.

Secure Communications

Communication with the web service is secured using HTTPS (HTTP over SSL). Using SSL provides:

• Privacy: traffic between the Sponsor and SIGNiX is encrypted to prevent eavesdropping.

• Data Integrity: traffic is protected from tampering with a Message Authentication Code.

• Server Authentication: the Sponsor can ensure it communicates with SIGNiX and not an imposter. The client (Sponsor) authenticates the server's identity by checking the SSL certificate presented by the web server; this is known as server-side SSL. The client's SSL library typically checks the SSL certificate by verifying that the signature on the server's certificate is from a trusted certificate authority (CA).

Client Authentication

The server authenticates the client's identity by checking a user ID / password pair included in each web service request.

Timing

The web methods are synchronous, meaning that the client posts a request and waits for a response from the server.

Because the web method will take a few moments to execute, the client should update its user interface while the call is in progress. For example, the client could display "Please wait while the documents are submitted..." during the SubmitDocument call.

Note that large requests (50MB+, 50+ documents, or long, multi-hundred page PDFs) could cause SubmitDocument response times in production to exceed 60 seconds. If you are planning on submitting large transaction sizes, please be sure to share this information with SIGNiX and accommodate these longer response times within your application. The AddDocument API call may also be appropriate in this case (released as part of Release 181 in February 2026) as it allows an integrator to send a smaller initial SubmitDocument call and then send successive AddDocument calls to that suspended transaction.

API Calls

The sections below provide details for each web method and describe the XML structure of the corresponding request and response.

SubmitDocument

The SubmitDocument method submits a set of documents for secure delivery to, and optional viewing and signature by, a set of end users (signers / parties). Note that despite the term 'Document,' the call is actually used to start an entire SIGNiX transaction. It can be used for multiple documents.

After the SIGNiX system successfully receives the set of submitted documents, it performs additional checks and then sends an email to the first party with a link to click to pick up the documents in order to sign and/or view them.

SubmitDocument - Request XML

Because the request XML for SubmitDocument is large, an overview of its structure is given below. Only elements that contain other elements are shown here. As in the notation for regular expressions, '+' indicates the element appears once or more than once, and '|' indicates a choice of alternatives. Parenthesis indicates optional elements, and indentation indicates embedding.

SubmitDocumentRq

CustInfo

Data

(MemberInfo)+

(Form)+

(SignatureLine | InitialLine | View)+

The detailed structure of the response is specified in the XML schema file. An annotated example of the request XML is as follows.

XML

<?xml version="1.0" ?>
<SubmitDocumentRq xmlns="urn:com:signix:schema:sdddc-1-1">
<!-- Occurs once only -->
<CustInfo>
    <!-- Assigned by SIGNiX when Client is set up (Case Sensitive) -->
    <Sponsor>oem</Sponsor>
    <Client>oemclient</Client>
    <UserId>oemclient</UserId>
    <Pswd>your-password-here</Pswd>
    <!-- Optional. Used to indicate who is the billable party. Can be left blank. Maximum length 50 -->
    <BillingRef>SmithRealty</BillingRef>
    <!-- Optional. Defaults to "SDD" -->
    <Workgroup>SDD</Workgroup>
    <!-- 'yes' for demo/test, 'no' for real transaction -->
    <Demo>yes</Demo>
    <!-- Content of the pickup email. Length 1..10000 -->
    <EmailContent>Your loan Documents are available.</EmailContent>
</CustInfo>
<!-- Occurs once only -->
<Data>
    <!-- Required. Length must be exactly 36 characters -->
    <TransactionID>aefd45aa-6a36-4ab5-8cc8-4dc6e895fa21</TransactionID>
    <!-- Required. Length 1..100 -->
    <DocSetDescription>Car Loan: John Smith</DocSetDescription>
    <!-- Optional, maxlen 255. Extension should be .ZIP -->
    <FileName>J-Smith_02242005_032557.zip</FileName>
    <!-- Required, maxlen 50 -->
    <SubmitterEmail>demo@signix.com</SubmitterEmail>
    <!-- Required, maxlen 50 -->
    <SubmitterName>Samuel Submitter</SubmitterName>
    <!-- Optional, maxlen 1000 -->
    <ContactInfo>If you need assistance, call 1-800-000-0000.</ContactInfo>
    <!-- Legacy parameter. Required -->
    <DeliveryType>SDDDC</DeliveryType>
    <!-- Optional, defaults to 'no' -->
    <SuspendOnStart>yes</SuspendOnStart>
    <!-- Optional -->
    <DistributionEmailContent>Fully executed documents attached.</DistributionEmailContent>
    <!-- Optional -->
    <DistributionEmailList>a@b.com; c@d.com</DistributionEmailList>
    <!-- Optional, defaults to "no" -->
    <DistributeToSubmitter>yes</DistributeToSubmitter>
    <!-- Optional, repeating -->
    <ClientPreference name="DateSignedTimeZone">GMT</ClientPreference>
    <!-- Optional -->
    <ClientPreference name="NotificationSchedule">{10,60,180}minutes</ClientPreference>
    <!-- Occurs once for each party -->
    <MemberInfo>
        <!-- Optional, maxlen 50 -->
        <RefID>MemberID-1</RefID>
        <!-- Optional -->
        <WorkflowOrder>1</WorkflowOrder>
        <!-- Required, format 123456789 -->
        <SSN>910000000</SSN>
        <!-- Required, format mm/dd/yyyy -->
        <DOB>00/00/0000</DOB>
        <!-- Required, maxlen 30 -->
        <FirstName>John</FirstName>
        <!-- Optional, maxlen 30 -->
        <MiddleName>Q</MiddleName>
        <!-- Required, maxlen 30 -->
        <LastName>Smith</LastName>
        <!-- Required, maxlen 50 -->
        <Email>demo@signix.com</Email>
        <!-- Optional, maxlen 30 -->
        <Street>1313 Mockingbird Ln</Street>
        <!-- Required -->
        <Service>SelectOneClick</Service>
        <!-- Required for SMSOneClick -->
        <MobileNumber>1112223333</MobileNumber>
    </MemberInfo>
    <Form>
        <!-- Optional, maxlen 50 -->
        <RefID>FormID-1</RefID>
        <!-- maxlen 100 -->
        <Desc>Express Application #1</Desc>
        <!-- Optional, maxlen 255 -->
        <FileName>JSmith_Application_Form.pdf</FileName>
        <MimeType>application/pdf</MimeType>
        <SignatureLine>
            <MemberInfoNumber>1</MemberInfoNumber>
            <SignField>Signix_Sig_A_Signature1</SignField>
        </SignatureLine>
        <Length>5631</Length>
        <Data>JVBERi0xLjQNJeLjz9MNCj ... YgMCBvYmogPDwvTGluZWFy</Data>
    </Form>
</Data>
</SubmitDocumentRq>

SubmitDocument - Additional Options & Capabilities

Document Subsets

SIGNiX can provide additional 'folder' hierarchy within a transaction to allow integrated applications to present groups (aka subsets) of documents that may be mandatory or optional. If this seems pertinent to your use case, please contact SIGNiX for additional details.

Notarization - Notary Party

Notaries are included in transactions via the MemberInfo element of SubmitDocument. Currently transactions can contain only ONE eNotary, and the eNotary MUST be the last signer.

The Notary must already be registered in SIGNiX. This allows the transaction to pull the appropriate commission information, etc from the notary's profile. If a registered Notary is found with the given email address, the system will use them as the notary and pick up all the other necessary information, including Service, from their account. If no matching Notary is registered at SIGNiX, the SubmitDocument request will return an error and the error message will indicate why the match failed.

The following example shows how to create an Notary party. A Notary MemberInfo must contain only the following elements, in the order they are shown.

XML

<MemberInfo>
    <!-- An optional client-chosen identifier for this party. The RefID is returned in reports that include party information. Optional, maxlen 50 -->
    <RefID>MemberID-1</RefID>
    <!-- If the WorkflowOrder element is used, the eNotary must have the highest WorkflowOrder number and must be the only party that has this number. Optional -->
    <WorkflowOrder>2</WorkflowOrder>
    <!-- Must be the email address of a registered eNotary. Required -->
    <Email>jbhnotarydemo1@gmail.com</Email>
    <!-- Set this element to true to indicate that this party is an eNotary. All the signatures associated with this party will be notarization signatures. Required for eNotary -->
    <NotaryInfoAdded>true</NotaryInfoAdded>
</MemberInfo>

Notarization - Notary Signature & Stamp

Notary signatures will be specified in SubmitDocument in the same way as any other party signature, except that it must contain a <NotaryStampField> element specifying the name of a field to display the Notary's stamp. The stamp field must be an empty PDF multi-line text field that is already present in the document when it is uploaded. The document designer is responsible for ensuring that this field is present and is appropriately sized and placed. IMPORTANT: The notary stamp field must be set to multi-line (Ff flag set to 4096), or the under-seal notary vendor text will not properly display. SIGNiX will not validate anything about this field other than its existence. A stamp field can only be associated to one signature.

When a transaction starts, every field that a notary signs must have a unique notary stamp field associated with it. Therefore, every <SignatureLine> field for a notary must either specify a NotaryStampField or the transaction must be marked as SuspendOnStart so that the missing stamp fields can be added in the Wizard.

Note as well that using GetAccessLink to display the 'wizard' tagging UI to the submitter is another way in which Notary signature and stamp can be applied to the document via drag-and-drop.

Notarization - Hold Email

Commonly, notaries will prefer for signers to receive their links to sign when the notary is ready to host/launch the Zoom meeting and is engaged with the signers / principals. In this case, we offer the ability to set a notary transaction to 'hold' the signer emails until the notary releases them. Note that this 'release' will require the integration to display the Status page to the notary using the GetAccessLink-Submitter call as described below. In order to initiate the hold email function, simply add the following element after the <SuspendOnStart> parameter. (Added in Release 174.1 - June 2024)

Acceptable time zones for use in the <Timezone> element are as follows.

US/Eastern
GMT
US/Central
US/Mountain
US/Pacific
US/Alaska
US/Aleutian
US/Hawaii
Canada/Atlantic
Africa/Lagos
Europe/London
Europe/Paris
Europe/Athens
Asia/Qatar
Europe/Moscow
Asia/Karachi
Asia/Kolkata
Asia/Bangkok
Asia/Shanghai
Asia/Tokyo
Australia/Sydney
Pacific/Auckland

Signer Attachments

By using the parameters below, an integrated application can prompt a signer to add supplemental documents to be returned back to the integrated application. These documents will not be signed; this is simply a way to ask signers to send back a copy of their utility bill, for example, or a copy of some other documentation. The attachment controls also allow the integrated, submitting application to customize the instructions shown to the signer, the number and type of documents / files requested, and finally whether the attachments are mandatory or not. NOTE: If attachments are made mandatory, the transaction will not be complete until that signer attaches the minimum number of file(s) requested. The transaction will remain 'in-process' until such time as attachments are added.

These parameters should be placed at the very bottom of the SubmitDocument xml, below the last <Form> (document) elements. If more than one signer will be prompted to add attachments, please use different values for the <RefID>, <Title> and update or remove any name-specific language. All elements & parameters are required unless otherwise stated.

XML

…
<Length>16417</Length>
<Data>********</Data>
</Form>

<UserAttachments>
    <!-- Required. If more than one signer will be prompted to add attachments, please use different values -->
    <RefID>ATT01</RefID>
    <MemberInfoNumber>1</MemberInfoNumber>
    <!-- Optional, but recommended -->
    <Title>Jack's Attachments</Title>
    <!-- Optional, but recommended -->
    <Description>This is a description of Jack's Attachments</Description>
    <FileSet>
        <!-- Required -->
        <Min>1</Min>
        <!-- Required -->
        <Max>2</Max>
        <!-- Required -->
        <AcceptFewerThanMin>no</AcceptFewerThanMin>
        <!-- Optional, but recommended -->
        <FewerThanMinChallenge>You have to attach something</FewerThanMinChallenge>
        <!-- Required -->
        <AcceptableTypes>PDF,JPG</AcceptableTypes>
        <!-- Required -->
        <CapturePriority>Primary</CapturePriority>
    </FileSet>
</UserAttachments>
</Data>
</SubmitDocumentRq>

SIGNiX Digital Billboard™

Released in November 2024, the Digital Billboard feature allows you to take advantage of the screen real estate shown to the signer after they complete the signing process on the Thank You for Signing page. With this new feature you can specify an image to show to each individual signer, a separate hover image, Alt text and a link that will open in a new tab when the signer clicks on it. In addition, you can control the location of the image above or below the text on the screen and even control the relative width of the image on the page.

Please use the elements below, placed at the end of any signer's <MemberInfo> section. (Added in Release 176.)

XML

<MemberInfo>...
    <PostSignatureImageLink>
        <!-- Required -->
        <ImageURL>add in URL for image</ImageURL>
        <!-- Required -->
        <TargetURL>add in URL to redirect the signer to in a new tab</TargetURL>
        <!-- Required -->
        <ImageAltText>Post Signature Image Link</ImageAltText>
        <!-- Optional -->
        <ImageHoverURL>add in URL for image</ImageHoverURL>
        <!-- Required -->
        <IsImageLocationAboveText>yes</IsImageLocationAboveText>
        <!-- Optional -->
        <ImageHeight>1</ImageHeight>
        <!-- Optional -->
        <ImageWidth>250</ImageWidth>
    </PostSignatureImageLink>
</MemberInfo>

XML

<?xml version="1.0" ?>
<SubmitDocumentRs xmlns ="urn:com:signix:schema:sdddc-1-1">
    <Status>
        <!-- Occurs once only -->
        <!-- One of the numeric SC_* values -->
        <StatusCode>0</StatusCode>
        <!-- Human-readable version of StatusCode -->
        <StatusDesc>success</StatusDesc>
    </Status>
    <Data>
        <!-- The SIGNiX identifier for the transaction -->
        <DocumentSetID>-5cb1ea45:119ddcc67bb:-7ad7-hkq0ep</DocumentSetID>
        <!-- Length 22 characters -->
        <PickupToken>IeCAsVBUv0ImkEStJuyDPd</PickupToken>
        <PickupLink>https://webtest.signix.biz/enter.jsp?m=102&amp;i=IeCA...yDPd</PickupLink>
    </Data>
</SubmitDocumentRs>

SubmitDocument - Limitations

When creating and sending a transaction via SIGNiX, it's important to be aware of certain file size and document limitations. These limits are in place to ensure a good signer experience and also to ensure smooth operation of various API flows.

Transactions are limited to a maximum of 99 unique documents and 99 parties, though SIGNiX recommends no more than 50-75 of each per transaction for the best results.

Each document in a transaction is also governed by file size limitations. In general, each document is limited to 10 MB each, though customers can discuss with SIGNiX provisions to expand that size up to 25 MB in certain use cases. SIGNiX recommends file sizes no larger than 5 MB.

Documents which are generated from a scanner before being sent through SIGNiX should be reviewed carefully for optimization (dpi, images, etc) to reduce file size and improve rendering for the signer.

If the CC function or <DistributionEmailList> are used, SIGNiX cannot guarantee delivery via email of completed documents to those recipients if the documents are larger than 5 MBs.

DownloadDocument

The DownloadDocument method allows for the pickup/downloading of all the completed documents for a Transaction along with its accompanying Audit Trail PDF. This call IS REQUIRED for all Transactions.

In order to implement a retention policy (document deletion / purge schedules) set by the DelDocsAfter parameter in SubmitDocument, BOTH the UseConfirmDownload parameter must be set to ‘true’ in the DownloadDocument call AND the ConfirmDownload call must be made post-download in order to confirm successful receipt of all the documents by the receiving Application. If not, retention polivcies will not be enforced. These are mandatory requirements if retention is desired. (In addition, you must contact SIGNiX to enable your account for document deletion.)

If a document set is complete, the client receives the downloaded documents, and the Confirm Download has been received and responded to, then this method has the side effect of changing the status of the document set on the SIGNiX Dashboard.

If the document set is in the post-completion availability period, then the document set status becomes "Pending Deletion".
If the document set's post completion availability period has expired, then the document set is ready for immediate deletion.
The post-completion availability period of a document set begins at the moment the document set becomes complete. Documents remain available on the server in the completed status until the client receives and confirms the downloaded documents, even if the post-completion availability period expired.

When the document set is deleted, the following happens:

The individual documents (the PDF files) are deleted.
The status of the transaction is set to Deleted, and the transaction is removed from the "Pending Deletion" folder.
The transaction may still be accessed when, for example, a user follows a URL link from the original pickup notification. After the user logs in, the transaction still displays the names of the parties and of the documents, but clicking the name of a document no longer displays it. The interface instructs the user to contact the Client/Submitter to obtain a copy of the documents if they did not save a copy when they first went through the pickup and signing process.

The IncludeAuditData parameter is REQUIRED and must be set to ‘true’ so a copy of the transaction Audit Trail will be included in the response. The Audit Trail may be received in digitally-signed PDF format (most common for easy storage and pull for clients needing a copy for legal purposes), digitally-signed XML format (useful for Applications that need values from the XML Response for back-office actions), or Both PDF and XML (for applications that need easy/human-readable for clients but servers also need to read the Response data). Note that SIGNiX does archive and may delete transaction data because OEM/Applications are expected to retrieve and store all transaction data. In the event that an Audit Trail is needed and it has been archived, there may be a Professional Services fee applied for its retrieval. If data has been found to have been deleted (per contract or other record retention rules), it is no longer retrievable.

DownloadDocument - Request XML

XML

<?xml version="1.0" ?>
<DownloadDocumentRq xmlns="urn:com:signix:schema:sdddc-1-1">
<!-- Occurs once only -->
<CustInfo>
    <Sponsor>oem</Sponsor>
    <Client>oemclient</Client>
    <UserId>oemclient</UserId>
    <Pswd>your-password-here</Pswd>
    <BillingRef>SmithRealty</BillingRef>
</CustInfo>
<!-- Occurs once only -->
<Data>
    <DocumentSetID>-147fb68b:1043a5db9ca:-7f5fid11or</DocumentSetID>
    <!-- Optional -->
    <IncludeFieldData>true</IncludeFieldData>
    <!-- Both element and value (true) are required -->
    <IncludeAuditData>true</IncludeAuditData>
    <!-- Required. pdf, xml, or both -->
    <AuditDataFormat>pdf</AuditDataFormat>
    <!-- Mandatory and required to implement retention policy -->
    <UseConfirmDownload>true</UseConfirmDownload>
    <!-- Optional -->
    <IncludeCertificateOfCompletion>true</IncludeCertificateOfCompletion>
    <!-- Optional -->
    <ExcludeDocuments>true</ExcludeDocuments>
</Data>
</DownloadDocumentRq>

XML

<?xml version="1.0" ?>
<DownloadDocumentRs xmlns ="urn:com:signix:schema:sdddc-1-1">
    <Status>
        <StatusCode>0</StatusCode>
        <StatusDesc>success</StatusDesc>
    </Status>
    <Data>
        <TransactionID>aefd45aa-6a36-4ab5-8cc8-4dc6e895fa21</TransactionID>
        <FileName>J-Smith_02242005_032557.zip</FileName>
        <Form>
            <Desc>Express Application #1</Desc>
            <FileName>J-Smith_Express_Application.pdf</FileName>
            <MimeType>application/pdf</MimeType>
            <Length>5631</Length>
            <Data>JVBERi0xLjQNJeLjz9MNCj...YgMCBvYmogPDwvTGluZWFy</Data>
        </Form>
        <AuditReport>
            <FileName>J-Smith_Express_Application_audit_trail.pdf</FileName>
            <MimeType>application/pdf</MimeType>
            <Length>5631</Length>
            <Data>JVBERi0xLjQNJeLjz9MNCj...YgMCBvYmogPDwvTGluZWFy</Data>
        </AuditReport>
    </Data>
</DownloadDocumentRs>

ConfirmDownload

Confirms that a DownloadDocument call successfully returned all of the signed/acted upon PDFs and its accompanying Audit Trail. This call is REQUIRED and assumes that once received, SIGNiX can safely archive or delete transaction data.

The ConfirmDownload completes the download process by changing the transaction status from "Complete" to "PendingDeletion". See the description of the DownloadDocument method for details.

ConfirmDownload - Request XML

An annotated example of the request XML is as follows.

XML

<?xml version="1.0" ?>
<ConfirmDownloadRq xmlns="urn:com:signix:schema:sdddc-1-1">
    <CustInfo>
        <Sponsor>oem</Sponsor>
        <Client>oemclient</Client>
        <UserId>oemclient</UserId>
        <Pswd>your-password-here</Pswd>
        <BillingRef>SmithRealty</BillingRef>
    </CustInfo>
    <Data>
        <DocumentSetID>-147fb68b:1043a5db9ca:-7f5fid11or</DocumentSetID>
    </Data>
</ConfirmDownloadRq>

XML

<?xml version="1.0" ?>
<GetAccessLinkRq xmlns="urn:com:signix:schema:sdddc-1-1">
    <CustInfo>
        <Sponsor>oem</Sponsor>
        <Client>oemclient</Client>
        <UserId>oemclient</UserId>
        <Pswd>your-password-here</Pswd>
    </CustInfo>
    <Data>
        <DocumentSetID>-147fb68b:1043a5db9ca:-7f5fid11or</DocumentSetID>
        <TransactionRole>Submitter</TransactionRole>
        <AllowTransactionStatusViewing>true</AllowTransactionStatusViewing>
        <AllowTransactionContextEditing>true</AllowTransactionContextEditing>
        <AllowDocumentFieldAndTaskEditing>true</AllowDocumentFieldAndTaskEditing>
        <AllowDocumentEditing>false</AllowDocumentEditing>
        <AllowParticipantEditing>false</AllowParticipantEditing>
        <Embedded>sameframe</Embedded>
        <ContainerOrigin>http://h5.yourco.com</ContainerOrigin>
        <FinishURL>http://www.yourco.com</FinishURL>
    </Data>
</GetAccessLinkRq>

XML

<?xml version="1.0" ?>
<GetAccessLinkRq xmlns="urn:com:signix:schema:sdddc-1-1">
    <CustInfo>
        <Sponsor>oem</Sponsor>
        <Client>oemclient</Client>
        <UserId>oemclient</UserId>
        <Pswd>your-password-here</Pswd>
    </CustInfo>
    <Data>
        <DocumentSetID>-147fb68b:1043a5db9ca:-7f5fid11or</DocumentSetID>
        <TransactionRole>MemberInfoNumber</TransactionRole>
        <GetNormalPickupLink>false</GetNormalPickupLink>
        <InpersonAuthentication>yes</InpersonAuthentication>
        <Embedded>sameframe</Embedded>
        <ContainerOrigin>http://h5.yourco.com</ContainerOrigin>
        <FinishURL>http://www.yourco.com</FinishURL>
        <CancelURL>http://www.yourco.com</CancelURL>
    </Data>
</GetAccessLinkRq>

CertifyDocument

This function is often used when a PDF document simply needs to be locked down and a time reference added to it to show that it was produced at a certain time. It does so by requesting a covering signature be applied to a document.

The type of signature to be applied is controlled by the signature policy, as specified the policy OID in the SignaturePolicyID element. The following policies are supported:

• 1.3.6.1.4.1.6693.4.2.20 – SIGNiX Certifying time-stamp. SIGNiX will insert a new, hidden signature field into the document and sign it with a PDF Document Modification Prevention and Detection (DocMDP) signature.

The certificate on the signature belongs to the SIGNiX Signature Authority, and is issued under the Adobe AATL program, like other signer signatures. It will cause a blue ribbon mark to appear above the document in the default configuration of Adobe Acrobat and Reader.

DocMDP signatures limit the types of changes that can be made after signing. The limitation desired can be specified in the “SubsequentChanges” element. Choices are NO_CHANGES, FORM_FILLING, or FORM_FILLING_AND_ANNOTATIONS.

This type of signature must be the first digital signature on a document, so the document must not have any digital signatures on it when submitted.

Digital signatures made under this policy have the legal effect of a pure time stamp: SIGNiX only asserts (in the signature reason field) that the signature represents a time stamp, showing that the document existed in the signed form at the time of signing. Verification of the signature provides evidence that the document has not changed since signing, other than in the ways allowed by the SubsequentChanges setting.

Any assertions about the trustworthiness of other information in the document, including any text or images of signatures, and communication of any information on how to evaluate the trustworthiness of the content are left to the customer.

CertifyDocument – Request

An annotated example of the request XML is as follows.

XML

<?xml version="1.0" ?>
<CertifyDocumentRq xmlns="urn:com:signix:schema:sdddc-1-1">
    <!-- Occurs once only -->
    <CustInfo>
        <!-- Assigned by SIGNiX when Client is set up (Case Sensitive) -->
        <Sponsor>oem</Sponsor>
        <Client>oemclient</Client>
        <UserId>oemclient</UserId>
        <Pswd>your-password-here</Pswd>
    </CustInfo>
    <!-- Occurs once only -->
    <Data>
        <!-- The signature policy to be used to sign the form. Required -->
        <SignaturePolicyID>1.3.6.1.4.1.6693.4.2.20</SignaturePolicyID>
        <!-- Optional. Defaults to NO_CHANGES. Case-sensitive. Options: NO_CHANGES, FORM_FILLING, or FORM_FILLING_AND_ANNOTATIONS -->
        <SubsequentChanges>NO_CHANGES</SubsequentChanges>
        <!-- Describes the document to be signed -->
        <Form>
            <!-- Optional, no default. maxlen 50. Appears in audit trail and is returned in the response -->
            <RefID>FormID-1</RefID>
            <!-- maxlen 100. Appears in the audit trail entry for the signing -->
            <Desc>Express Application #1</Desc>
            <!-- The type of document, maxlen 100. Supported: application/pdf -->
            <MimeType>application/pdf</MimeType>
            <!-- Optional. Defaults to blank. Owner password if the document has one -->
            <FormPassword>d8gj3%i2$^cs</FormPassword>
            <!-- Length of document to be signed, when decoded, in bytes -->
            <Length>5631</Length>
            <!-- The bytes of the entire document, encoded in Base64 format -->
            <Data>JVBERi0xLjQNJeLjz9MNCj...YgMCBvYmogPDwvTGluZWFy</Data>
            <!-- Optional. If present, Length and Data elements must be omitted -->
            <DocumentURL>https://www.---.com/form1.pdf</DocumentURL>
        </Form>
    </Data>
</CertifyDocumentRq>

XML

<?xml version="1.0" ?>
<CertifyDocumentRs xmlns="urn:com:signix:schema:sdddc-1-1">
    <!-- Occurs once only -->
    <Status>
        <!-- One of the numeric SC_* values -->
        <StatusCode>0</StatusCode>
        <!-- Human-readable version of StatusCode -->
        <StatusDesc>success</StatusDesc>
    </Status>
    <!-- Occurs when Status.StatusCode is 0. Returns the signed document -->
    <Data>
        <Form>
            <!-- A client-chosen RefID, echoed from the request -->
            <RefID>FormID-1</RefID>
            <!-- Document title, echoed from the request -->
            <Desc>Express Application #1</Desc>
            <!-- Matches the MimeType from the request -->
            <MimeType>application/pdf</MimeType>
            <!-- Length of the signed document, when decoded, in bytes -->
            <Length>5631</Length>
            <!-- The bytes of the entire signed document, encoded in Base64 format -->
            <Data>JVBERi0xLjQNJeLjz9MNCj...YgMCBvYmogPDwvTGluZWFy</Data>
        </Form>
    </Data>
</CertifyDocumentRs>

Update Notary List

The goal of the Notary List is to allow clients to make lists of frequently used, recommended, or required eNotaries. The Notary List section of the SIGNiX FlexAPI is not designed to serve as a search function across all SIGNiX notaries. Rather, it’s designed as a way for companies to create bespoke lists of notaries and associate certain criteria with them. Due to this fact, it’s not intended to be used with every notary use case – only those where (a) notaries are known in advance, (b) those notaries have a need to be categorized, and (c) there is a need outside of the host application to display lists of those notaries.

For example, let’s say a Company has an East office with 3 known SIGNiX notaries and a West office with two. Company could create a Notary List using the Update Notary List function for all 5 notaries, and associate the East and West criteria with all of them respectively, as well as perhaps State Commission, etc as other criteria. Then, when Company wanted to pull a list of notaries in the East office, the Read Notary List function could be called to list the 3 notaries and their email addresses. The user could then choose one of those, and that notary info could be added to a SubmitDocument request.

Notary lists will be created and maintained via B2B API calls. Each eNotary can be given up to three criteria that can be used to get filtered lists for different purposes.

Update Notary List – Request

Update the criteria for the specified notary if they are already in the client’s list, otherwise add them to the list or in fact, create one.

XML

<?xml version="1.0"?>
<NotaryListUpdateEntryRq xmlns="urn:com:signix:schema:sdddc-1-1">
    <!-- Occurs once only -->
    <CustInfo>
        <!-- Assigned by SIGNiX when Client is set up (Case Sensitive) -->
        <Sponsor>oem</Sponsor>
        <Client>oemclient</Client>
        <UserId>oemclient</UserId>
        <Pswd>your-password-here</Pswd>
    </CustInfo>
    <!-- Occurs once only -->
    <Data>
        <!-- Required. Must be the email address of a registered eNotary -->
        <Email>jbhnotarydemo1@gmail.com</Email>
        <!-- Optional. Controls which submitters can access this eNotary -->
        <Availability>
            <!-- Optional. Available to all users in all Workgroups for the named client or sponsor -->
            <Global/>
            <!-- Optional. Occurs once per linked workgroup. Max 50 chars -->
            <Workgroup>SDD</Workgroup>
            <!-- Optional. Occurs once per linked submitter -->
            <Submitter>
                <!-- Required. The SIGNiX user ID of a submitter -->
                <UserId>jharris</UserId>
            </Submitter>
        </Availability>
        <!-- Optional. max 25 characters each. Used to get filtered lists of eNotaries -->
        <Criteria1>New Jersey</Criteria1>
        <Criteria2>Office 25</Criteria2>
        <Criteria3>Blue Team</Criteria3>
    </Data>
</NotaryListUpdateEntryRq>

XML

<?xml version="1.0" ?>
<NotaryListUpdateEntryRs xmlns="urn:com:signix:schema:sdddc-1-1">
    <!-- Occurs once only -->
    <Status>
        <!-- One of the numeric SC_* values -->
        <StatusCode>0</StatusCode>
        <!-- Human-readable version of StatusCode -->
        <StatusDesc>success</StatusDesc>
    </Status>
    <!-- Occurs when Status.StatusCode is 0 -->
    <Data>
        <!-- Action taken. Value is either Added or Updated -->
        <Action>Added</Action>
    </Data>
</NotaryListUpdateEntryRs>

XML

<?xml version="1.0"?>
<NotaryListReadEntryRq xmlns="urn:com:signix:schema:sdddc-1-1">
    <!-- Occurs once only -->
    <CustInfo>
        <!-- Assigned by SIGNiX when Client is set up (Case Sensitive) -->
        <Sponsor>oem</Sponsor>
        <Client>oemclient</Client>
        <UserId>oemclient</UserId>
        <Pswd>your-password-here</Pswd>
    </CustInfo>
    <!-- Occurs once only -->
    <Data>
        <!-- Optional. Filter the list by availability to submitters -->
        <Availability>
            <!-- Optional. Include any eNotary available to all users in all Workgroups -->
            <Global/>
            <!-- Optional. Max 50 chars. Occurs once per desired workgroup -->
            <Workgroup>SDD</Workgroup>
            <!-- Optional. Occurs once per desired submitter -->
            <Submitter>
                <!-- Required. The SIGNiX user ID of a submitter -->
                <UserId>jharris</UserId>
            </Submitter>
        </Availability>
        <!-- Optional. max 25 characters each. Response only contains entries that exactly match -->
        <Criteria1>New Jersey</Criteria1>
        <Criteria2>Office 25</Criteria2>
        <Criteria3>Blue Team</Criteria3>
    </Data>
</NotaryListReadEntryRq>

XML

<?xml version="1.0" ?>
<NotaryListReadEntryRs xmlns="urn:com:signix:schema:sdddc-1-1">
    <!-- Occurs once only -->
    <Status>
        <!-- One of the numeric SC_* values -->
        <StatusCode>0</StatusCode>
        <!-- Human-readable version of StatusCode -->
        <StatusDesc>success</StatusDesc>
    </Status>
    <!-- Occurs when Status.StatusCode is 0 -->
    <Data>
        <!-- Occurs once for each eNotary in the list -->
        <NotaryData>
            <!-- Required -->
            <FirstName>John</FirstName>
            <!-- Optional -->
            <MiddleInitial>B</MiddleInitial>
            <!-- Required -->
            <LastName>Stamper</LastName>
            <!-- Required -->
            <Email>jbhnotarydemo1@gmail.com</Email>
            <!-- Required -->
            <NotaryState>NJ</NotaryState>
            <!-- Required -->
            <NotaryCommissionNumber>274649375</NotaryCommissionNumber>
            <!-- Required -->
            <NotaryCommissionExpirationDate>10-01-2056</NotaryCommissionExpirationDate>
            <!-- Optional -->
            <Availability>
                <!-- Optional. Available to all users in all Workgroups -->
                <Global/>
                <!-- Optional. Max 50 chars. Occurs once per linked workgroup -->
                <Workgroup>SDD</Workgroup>
                <!-- Optional. Occurs once per linked submitter -->
                <Submitter>
                    <!-- Required. The submitter's SIGNiX user ID -->
                    <UserId>jharris</UserId>
                </Submitter>
            </Availability>
            <!-- Optional. max 25 characters each -->
            <Criteria1>New Jersey</Criteria1>
            <Criteria2>Office 25</Criteria2>
            <Criteria3>Blue Team</Criteria3>
        </NotaryData>
    </Data>
</NotaryListReadEntryRs>

XML

<?xml version="1.0"?>
<NotaryListRemoveEntryRq xmlns="urn:com:signix:schema:sdddc-1-1">
    <!-- Occurs once only -->
    <CustInfo>
        <!-- Assigned by SIGNiX when Client is set up (Case Sensitive) -->
        <Client>oemclient</Client>
        <UserId>oemclient</UserId>
        <Pswd>your-password-here</Pswd>
    </CustInfo>
    <!-- Occurs once only -->
    <Data>
        <!-- Required. Must be the email address of a registered eNotary -->
        <Email>jbhnotarydemo1@gmail.com</Email>
    </Data>
</NotaryListRemoveEntryRq>

XML

<?xml version="1.0" ?>
<NotaryListRemoveEntryRs xmlns="urn:com:signix:schema:sdddc-1-1">
    <!-- Occurs once only -->
    <Status>
        <!-- One of the numeric SC_* values -->
        <StatusCode>0</StatusCode>
        <!-- Human-readable version of StatusCode -->
        <StatusDesc>success</StatusDesc>
    </Status>
    <!-- Occurs when Status.StatusCode is 0 -->
    <Data>
        <!-- Action taken. Value is either Removed or Not Found -->
        <Action>Removed</Action>
    </Data>
</NotaryListRemoveEntryRs>

Additional Information

The sections below contain pertinent information relating to authentication, status codes and other items relevant to development.

Client Preference Overrides

The ClientPreference request element allows service configuration parameters to be overridden for a specific transaction. Each parameter is specified as a name/value pair. The format is as follows:

<ClientPreference name="NAME">VALUE</ClientPreference>

There are other preferences that SIGNiX can configure outside of a specific transactional context. Please contact SIGNiX for more details if additional customization options are required.

The available parameters are shown in the following table:

Name / Meaning	Allowed Values
AllowSignatureGraphic Determines whether a user can draw their signature when they register. If set to required, they will not be allowed to use a font-based signature.	yes no required
AuditTrailWithCC The audit trail of the transaction will be included as a PDF attachment to the CC (Carbon Copy) email.	yes no
BrowserAutofill Toggles the browser's autocomplete attribute of HTML form input fields.	yes no
DateSignedFormat Sets the format of the date field associated with a signature line.	MM/dd/yyyy hh:mm a z MMMM dd, yyyy hh:mm a z dd MMMM yyyy hh:mm a z dd/MMM/yyyy hh:mm a z dd/MM/yy hh:mm a z dd/MM/yyyy hh:mm a z
DateSignedTimeZone This preference sets the default time zone for the Wizard's date field Properties Dialog.	GMT US/Eastern US/Central US/Mountain US/Pacific US/Alaska US/Aleutian US/Hawaii
EmailFromName Allows all transaction emails (pickup, reminder, expiration) to feature a custom ‘friendly’ from name in the From email address.	50 characters
MiddleName Determines how middle names appear.	no preference as submitted middle initial full middle name
NextPartyLink This preference determines whether the party completion page supports immediate login by the next party. When a party finishes all their signatures and other actions in a transaction, a completion page appears. If there is a next party, the next party is authenticated via interactive questions, and this preference is set to “yes”, then the completion page will contain a link that the next party can click on to log in to the transaction. Otherwise, the completion page just indicates that the next party has been notified, but does not provide a login link.	yes no

Authentication / Service Types

When using SIGNiX e-Sign, there are several options for authentication (<Service>) for each signer. Whatever method is chosen for each Party, in a Transaction, is applicable to the entire transaction for that specific Party. Below is each authentication option available for each Party as well as the specific Authentication Behavior, Signing Flow and XML Specs to deliver. The ($) next to the title in the descriptions below specifies which authentication types may incur additional costs.

Password Only or No Password Required
2 Factor Authentication (OTP via Text or Voice)
KBA – Knowledge-based Authentication Questions (Not Recommended)
KBA-ID – Knowledge-based Authentication with ID Check – NOTARY ONLY
IDVerify – Credential Analysis with Face Biometrics

The following authentication options are no longer available for new integrations, but the API details are provided for informational purposes.

Know Your Customer (KYC) – DEPRECATED
Email Only w/ Submitted Questions – DEPRECATED
Know Your Customer (KYC) w/Submitted Questions – DEPRECATED

Password Only or No Password Required

Behavior

Signer will not go through external authentication – SSN/DOB not required.

Flow

Signer accepts Consent (may open it to read it)
- Creates Signing Password (SelectOneClick) or no Signing Password (express)
- Gains access to doc(s)
Signer clicks on each initial/signature
Signer clicks “Finish” button

NOTE: Using express will omit the creation and use of a Signing Password. This means that access to signed documents on the return link will not be secured, other than through email. Also, the signature appearance will not be saved.

XML Specs

To be delivered in SubmitDocument Call for Party (Test & Production).

SSN = 910000000
DOB = 00/00/0000
Service = ‘SelectOneClick’ (Signing Password) or ‘express’ (no Signing Password)

2 Factor Authentication (OTP Via Text or Voice) ($)

Behavior

Signer will be prompted to enter a one-time password code sent via SMS text message to their mobile phone or voice call.

Flow

Signer accepts Consent (may open it to read it)
- Receives text to their Mobile Phone with a one-time code. Enters code.
- Creates Signing Password (SMSNoIntent) or no Signing Password (SMSNoPassword)
- Gains access to doc(s)
Signer clicks on each initial/signature
Signer clicks “Finish” button

NOTE: Using SMSNoPassword will omit the creation and use of a Signing Password. This means that access to signed documents on the return link will not be secured by a password, but the signer will be required to enter a new one-time password / text code. Also, the signature appearance will not be saved.

NOTE 2: When in Demo mode (i.e. <Demo>yes</Demo>), the signer will see a ‘999999’ automatically entered into the dialog box for the code. In demo mode, the system ignores the OTP password for testing purposes. Turning demo mode off will require the correct OTP code sent to the mobile device.

XML Specs

To be delivered in SubmitDocument Call for Party (Test & Production).

SSN = 910000000
DOB = 00/00/0000
Service = ‘SMSNoIntent’ (requires creation of Signing Password) OR ‘SMSNoPassword’ (Signing Password not created or required)
<MobileNumber> (Domestic 10-digit numbers only. International SMS support is available for an additional fee.)

NOTE: If international numbers are sent, the following format rules apply. All international numbers must start with a ‘+’ (plus) sign and country code. Also do not include the prefix for ‘international’ dialing (i.e. 011). A space may or may not be used after the country code. After that, NO spaces allowed.

Examples:
WRONG: <MobileNumber>+01154 9 11 3011 ****</MobileNumber>
WRONG: <MobileNumber>+54 9 114937****</MobileNumber>
CORRECT: <MobileNumber>+54 9113011****</MobileNumber>
CORRECT: <MobileNumber>+549113011****</MobileNumber>

KBA-ID – Knowledge-based Authentication Questions with ID Check ($) – Notary ONLY

Behavior

NOTE: This authentication method may ONLY be used for notarization transactions. It cannot be used in non-notary scenarios.

Required for most states for remote online notarization (RON). Signer will go through external authentication – SSN, Name, DOB required. Confirms association of name with DOB and SSN. Confirms if alive and other checks. Signer must then answer several multiple choice questions from 30 years of public database information. Finally, signer will be prompted to take a picture of their driver's license or passport for automated analysis.

Flow

Signer accepts Consent (may open it to read it)
- Enters last 4 of SSN & full DOB (unless SubmitDocument required that signer would enter full 9 digit SSN)
- Answers public record-based questions
- Takes pictures of ID
- Creates Signing Password
- Gains access to doc(s)
Signer clicks on each initial/signature
Signer clicks “Finish” button

XML Specs

To be delivered in SubmitDocument Call for Party (Test & Production).

IMPORTANT: Replace <SSN> with <SSNLast4> if using KBA-ID-SSN4 (preferred). Note that the <WorkflowOrder> element must also be included.
SSN = ‘real’ data (Production) OR 0000 (Production, if signer will provide for KBA-ID-SSN4) OR 000000000 (Production, if signer will provide for KBA-ID); “0001 + random 5” (Webtest) – avoid ‘0001234..’, ‘0001111…’, etc.
DOB = ‘real’ data (Production) OR 00/00/0000 (Production, if signer will provide); Use any DOB over 18 yrs old (Webtest)
Service = ‘KBA-ID-SSN4’ (preferred) OR ‘KBA-ID’ (requires 9 digit SSN)

ID Verify – Credential Analysis with Face (selfie) Biometrics ($)

Behavior

Can be used for both RON (in certain states) as well as traditional digital signature transactions. Signer will be prompted to take a picture of their driver's license or passport for automated analysis and then also asked to take a picture of their face multiple times at different angles. These pictures will be compared to the face on the identity credential and must match.

Flow

Signer accepts Consent (may open it to read it)
- Takes pictures of ID and face as prompted
- Creates Signing Password
- Gains access to doc(s)
Signer clicks on each initial/signature
Signer clicks “Finish” button

XML Specs

To be delivered in SubmitDocument Call for Party (Test & Production).

SSN = 910000000
DOB = 00/00/0000
Service = ‘IDVerifyBiometric’

Know Your Customer (KYC) ($) – NOT AVAILABLE / DEPRECATED

Behavior

Signer will go through external authentication – SSN, Name, DOB required. Confirms association of name with DOB and SSN. Also confirms if alive and other checks.

Flow

Signer accepts Consent (may open it to read it)
- Enters last 4 of SSN & full DOB (unless SubmitDocument required that signer would enter, in which case full 9 digit SSN required)
- Creates Signing Password (KYCNoIntent) or no Signing Password (express)
- Gains access to doc(s)
Signer clicks on each initial/signature
Signer clicks “Finish” button

XML Specs

To be delivered in SubmitDocument Call for Party (Test & Production).

SSN = ‘real’ data (Production) OR 000000000 (Production, if signer will provide); “0001 + random 5” (Webtest) – avoid ‘0001234..’, ‘0001111…’, etc.
DOB = ‘real’ data (Production) OR 00/00/0000 (Production, if signer will provide); Use any DOB over 18 yrs old (Webtest)
Service = ‘KYCNoIntent’ (Signing Password) or ‘express’ (no Signing Password)

KBA – Knowledge-based Authentication Questions ($) – NOT RECOMMENDED

Behavior

Signer will go through external authentication – SSN, Name, DOB required. Confirms association of name with DOB and SSN. Confirms if alive and other checks. Signer must answer several multiple choice questions from 30 years of public database information. SIGNiX does NOT recommend using this authentication type, but can accommodate if needed.

Flow

Signer accepts Consent (may open it to read it)
- Enters last 4 of SSN & full DOB (unless SubmitDocument required that signer would enter, in which case full 9 digit SSN required)
- Answers public record-based questions
- Creates Signing Password
- Gains access to doc(s)
Signer clicks on each initial/signature
Signer clicks “Finish” button

XML Specs

To be delivered in SubmitDocument Call for Party (Test & Production).

SSN = ‘real’ data (Production) OR 000000000 (Production, if signer will provide); “0001 + random 5” (Webtest) – avoid ‘0001234..’, ‘0001111…’, etc.
DOB = ‘real’ data (Production) OR 00/00/0000 (Production, if signer will provide); Use any DOB over 18 yrs old (Webtest)
Service = ‘KBANoIntent’

Email Only w/Submitted Questions – NOT RECOMMENDED / DEPRECATED

NOTE: Question and answer pairs such as these may be abused in certain situations as the submitter or an organization representative can find the answer(s) readily and could possibly authenticate themselves as the signer. Therefore, SIGNiX does NOT recommend using this authentication type unless proper risk mitigation and acceptance discussions have taken place in your organization.

Behavior

Signer will not go through external authentication, but will be asked to answer questions which are provided by the submitting system. SSN/DOB not required.

Flow

Signer accepts Consent (may open it to read it)
- Answers Submitter's Question(s)
- Creates Signing Password
- Gains access to doc(s)
Signer clicks on each initial/signature
Signer clicks “Finish” button

XML Specs

To be delivered in SubmitDocument Call for Party (Test & Production).

SSN = 910000000
DOB = 00/00/0000
Service = ‘SelectOneClick’
Question and Answer (max of 9) within <MemberInfo> element, underneath <Service>

<Q1>What is the last name of your best friend?</Q1> maxlen 1000
<A1>Smith</A1> maxlen 1000

<Q2>What is the passphrase provided by your agent?</Q2>
<A2>applesauce</A2>

... Additional question/answer pairs, if needed.

Know Your Customer (KYC) w/Submitted Questions ($) – NOT AVAILABLE / DEPRECATED

Behavior

Signer will go through external authentication – SSN, Name, DOB required. Confirms association of name with DOB and SSN. Also confirms if alive and other checks. Will also be asked to answer questions which are provided by the submitting system.

Flow

Signer accepts Consent (may open it to read it)
- Enters last 4 of SSN & full DOB (unless SubmitDocument required that signer would enter, in which case full 9 digit SSN required)
- Answers Submitter's Question(s)
- Creates Signing Password
- Gains access to doc(s)
Signer clicks on each initial/signature and enters Signing Password
Finishes after last mandatory signature

XML Specs

To be delivered in SubmitDocument Call for Party (Test & Production).

SSN = ‘real’ data (Production) OR 000000000 (Production, if signer will provide); “0001 + random 5” (Webtest) – avoid ‘0001234..’, ‘0001111…’, etc.
DOB = ‘real’ data (Production) OR 00/00/0000 (Production, if signer will provide); Use any DOB over 18 yrs old (Webtest)
Service = ‘select’
Question and Answer (max of 9) within <MemberInfo> element, underneath <Service>

<Q1>What is the last name of your best friend?</Q1> maxlen 1000
<A1>Smith</A1> maxlen 1000

<Q2>What is the passphrase provided by your agent?</Q2>
<A2>applesauce</A2>

... Additional question/answer pairs, if needed.

Status Codes

This section describes the various StatusCode and StatusDesc values that can be returned and explains them. Note that in addition to being a human-readable form of StatusCode, StatusDesc often provides additional detail about the cause of an error.

SIGNiX has some generic Status Codes already in use for other web services that are reused here. This is not an inclusive list. Other errors may be returned. Please submit any questions to your SIGNiX representative.

Status Code	Value	Notes
SC_OK	0
SC_INTERNAL_ERROR	100	Generic errors start here.
SC_BAD_REQUEST	101
SC_UNAUTHORIZED	102
SC_BAD_FUNCTION	103
SC_BAD_PARAMETER	104
SC_NOT_FOUND	105
SC_TOO_MANY_REQUESTS	106	Customer request rate limit. May retry.
SC_BUSY	107	Global request rate limit. May retry.
SC_MEMBER_REGISTERED	200	Specific errors start here.
SC_MEMBER_NOT_REGISTERED	201	Deprecated.
SC_MEMBER_NOT_REGISTERED_PING_PASS	201	As of Jul’2007.
SC_SSN_EXISTS_DOB_MISMATCH	202
SC_SSN_EXISTS_NAME_MISMATCH	203
SC_MEMBER_CANNOT_USE_SDDDC	204
SC_DOCUMENT_SET_ALREADY_SUBMITTED	205
SC_MEMBER_NOT_REGISTERED_PING_FAIL	206

PDF Details and Requirements

For AcroForms (PDFs made with Acrobat), we support PDF version 1.5 and up. The older the version, the more likely clients will be able to open it without upgrading their installation of Acrobat or Reader.

The documents must be unencrypted.

For signature fields, we just need regular PDF signature fields. Each field must be positioned over a signature line in the document, and each field must have a name that is unique within the document.

In addition to signature fields, we also support what we call signature information fields. These are regular PDF fields that we automatically update at signing time with information about specific signatures.

Right now we support one kind of signature information field, the signing date field. This is a plain text field that we will fill automatically with the time of signing. By default, the date is in U.S. Eastern time zone, and only shows the date, not the time. When the documents are uploaded, there is a field in the transaction metadata that allows this field to be formatted arbitrarily, include the time, and be reported in other time zones, or in UTC (Zulu). The time zone and format that this field will be reported in is fixed at the time we receive the documents.

Glossary

Transaction

A Transaction is a set of one or multiple documents that can be digitally signed, acknowledged or reviewed by one or multiple signers and is submitted together for execution through SIGNiX.

PDF

Portable Document Format, aka ISO 32000-1. This is the document format that SIGNiX utilizes due to its capability to embed legal evidence, maturity and backwards compatibility. It must be AcroForm (most common format) and not XFA (Adobe LiveCycle).

Audit Trail

This is a critical piece of evidence that captures every action and event that transpired during a transaction, including emails sent, identity authentications, signatures and other items. An audit trail is a separate record (in either PDF or XML format) that lets relying parties understand who interacted with any and all of the documents throughout a transaction lifecycle.

Push Notifications

Throughout the transaction lifecycle, these real-time alerts are sent from SIGNiX to your systems to notify them as various milestones occur, including, for example, when a signer completes all of his tasks or when they decide to opt out of using a digital signature, as well as notices of completed or expired transactions. More information is available here.

References

Supporting Files (Code examples, schemas, XML examples, test documents, Base64 encode/decode and JAR files) – .ZIP File (Virus scanned) – Updated July 2018
Understanding SIGNiX Signatures & Audit Trails, v2 – January 2021

FlexAPI™ Documentation

Introduction

Basic Integration Workflows

Simple Document Delivery and Signature - No Embedded UI

Embedding the SIGNiX 'Wizard' Interface

Embedding the SIGNiX Signing Experience

Embedding Both the SIGNiX 'Wizard' Interface & Signing Experience

Transport Details

HTTP Request

HTTP Response

Web Service URL

Secure Communications

Client Authentication

Timing

API Calls

SubmitDocument

SubmitDocument - Request XML

SubmitDocument - Additional Options & Capabilities

Document Subsets

Notarization - Notary Party

Notarization - Notary Signature & Stamp

Notarization - Hold Email

Notarization - Schedule Meeting

Signer Attachments

Signature Groups (DEPRECATED - No longer supported)

SIGNiX Digital Billboard™

SubmitDocument - Response XML

SubmitDocument - Limitations

DownloadDocument

DownloadDocument - Request XML

DownloadDocument - Response XML

ConfirmDownload

ConfirmDownload - Request XML

ConfirmDownload - Response XML

GetAccessLink

GetAccessLink - Submitter Request

GetAccessLink - Signer Request

GetAccessLink - Response

CertifyDocument

CertifyDocument – Request

CertifyDocument – Response

Update Notary List

Update Notary List – Request

Update Notary List – Response

Read Notary List

Read Notary List – Request

Read Notary List – Response

Remove from Notary List

Remove from Notary List – Request

Remove from Notary List – Response

Additional Information

Client Preference Overrides

Authentication / Service Types

Password Only or No Password Required

2 Factor Authentication (OTP Via Text or Voice) ($)

KBA-ID – Knowledge-based Authentication Questions with ID Check ($) – Notary ONLY

ID Verify – Credential Analysis with Face (selfie) Biometrics ($)

Know Your Customer (KYC) ($) – NOT AVAILABLE / DEPRECATED

KBA – Knowledge-based Authentication Questions ($) – NOT RECOMMENDED

Email Only w/Submitted Questions – NOT RECOMMENDED / DEPRECATED

Know Your Customer (KYC) w/Submitted Questions ($) – NOT AVAILABLE / DEPRECATED

Status Codes

PDF Details and Requirements

Glossary

References

Other API Calls

Additional Information

DevCommunity Sitemap