#Notary application wizard pdf
Often, PDF documents intended for signature do not already have PDF fields / tags associated with the tasks that a signer may need to complete. 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. PDF documents and audit trail are returned.Ĥ. The integrated application sends a DownloadDocument call to SIGNiX, referencing the DocumentSetID provided earlier.
#Notary application wizard download
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.ģ. When each signer is finished, a push notification ('part圜omplete') is returned to the integrated application. Signers will click the link, authenticate (optionally) and review and sign the document(s). Email(s) sent to the signer(s) with a link to sign. A push notification ('Send') is sent back to the system indicating the transaction is sent.Ģ. Integrated application receives a response including a SIGNiX DocumentSetID which will be used in future calls. SubmitDocument transfers all information about the transaction to SIGNiX, including signer info, PDF document(s) and tasks to complete. 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.ġ. 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. Simple Document Delivery and Signature - No Embedded UI 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. 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 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).
(For example, don't place before in the element). Variations from these specs will lead to error messages. Please note that the element positioning is in the correct order throughout this document. For each web method, this document describes the XML structure of the request and of the matching response. The operations that can be performed by the web service are also referred to as web methods.
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. This interface allows customer servers to interact directly with the SIGNiX servers to create new transactions, monitor their progress, and download finished documents.Ī document sponsor ("Sponsor") makes B2B requests to SIGNiX and receives responses. This document specifies the business-to-business (B2B) interface for the SIGNiX Business to Business (B2B) interface (aka FlexAPI).
Embedding Both the SIGNiX 'Wizard' and Signing Experience (with GetAccessLink-Submitter and -Signer).Embedding the SIGNiX Signing Experience (with GetAccessLink-Signer).Embedding the SIGNiX 'Wizard' Interface (with GetAccessLink-Submitter).Simple Document Delivery & Signing - No Embedded UI.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. Accessing the powerful, secure SIGNiX service is as easy as a few simple API calls.
0 kommentar(er)
