Publish Workflow Completion Report

A SigningHub Enterprise Admin can configure their respective SigningHub enterprise level account to automatically publish a workflow completion report (i.e. in the form of document logs) as soon as a workflow initiated by one of its Enterprise Users is completed. The workflow completion report is an XML file which is sent by SigningHub to an external server URL that is configured by the Enterprise Admin at the time of enabling the workflow completion report in the SigningHub > Enterprise > Integrations > Workflow Completion Report screen.

Business application developer is required to develop an HTTP POST request handler and make it accessible to SigningHub via network/internet accessible HTTP/HTTPS URL. SigningHub does not support any HTTP authentication scheme thus the HTTP request handler must not require any authentication prior to accepting the HTTP POST request from SigningHub. Once the HTTP POST request is received, HTTP request handler should extract the XML bytes from the HTTP POST request and reconstruct the original XML.

The format of the HTTP POST request and the workflow completion report XML structure that is sent to the external application server URL is described below.

Posting of the document is optional and configured via the checkbox on the integrations screen referenced above. Note for document packages that contain only a single document the PDF itself is Base64 encoded and sent in the "Document" tag. Conversely, for packages containing two or more documents, a Base64 encoded ZIP file is sent. Therefore, consideration must be given to how the received document is processed.

Prior to the actual POST SigningHub tests the connectivity of the service using HTTP HEAD call. If this test succeeds the Workflow Completion Report is sent. Otherwise, no attempt is made.

Note due to legacy support the "DocumentID" tag now contains the SigningHub package ID, and not the individual document ID. Prior to version seven of SigningHub there was no concept of packages. Hence, the document ID was always used. Post version seven every document is part of a SigningHub package. Each document within a package still retains a unique ID but these are different to the package one.

HTTP Verb	POST
Content-Type	text/xml
Content-Length	<length of the XML content in bytes>
Request Body	<?xml version="1.0" encoding="utf-8"?> <DocumentLogs xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DocumentID>1001</DocumentID> <DocumentName>Sales Contract 101</DocumentName> <DocumentType>PDF</DocumentType> <Document> JVBERi0xLjQNCiXIycrLDQo2IDAg…</Document> <Actions> <Action> <DateTime>2016-06-06T11:17:22.173</DateTime> <Type>SIGNED</Type> <UserID>jc10@ascertia.com</UserID> <EnterpriseName>AscertiaJC10</EnterpriseName> <Information> <Type>KEY_LOCATION</Type> <Value>SERVER</Value> </Information> </Action> </Actions> </DocumentLogs>

The detail of each item provided in the request and response is provided below:

Item Details
Names	Description
Request Parameters
DocumentLogs	It’s the root element of the report.
DocumentID	Unique ID of the SigningHub package. This is the package that contains the documents themselves.
DocumentName	Name of the SigningHub package.
DocumentType	Type of the document e.g. PDF.
Document (Optional)	Complete document in Base64 encoded format if the package contains a single PDF document. For packages that contain multiple documents the Base64 encoded ZIP file of the package is sent.
Actions	It is a parent element which contains the list of all individual actions performed on the document.
Actions > Action	It contains the detail of an action performed on the document e.g. whether the document was opened, signed, reviewed etc.
Action > DateTime	Date and time when the action was performed.
Action > Type	Type of action performed on the document. Few possible actions are: - UPLOADED - ADDED_FROM_LIBRARY - OPENED - TEMPLATE_APPLIED - SHARED - CLOSED - FILLED_FORM - FILLED_INITIALS - SIGNED_IN_PERSON - SIGNED - REVIEWED_DOCUMENT - DECLINED_DOCUMENT - UPDATED - COMPLETED
Action > UserID	The email address of the user who performed the action.
Action > EnterpriseName	Name of the enterprise to which the user belongs.
Action > Information	It is a parent element which encloses additional information about the action performed by the user.
Information > Type	It tells what type of information is this e.g. for SIGNED action it contains KEY_LOCATION showing whether user signed using a server held key, locally held key or a mobile held key.
Information > Value	It contains the value corresponding to the type of the additional information provided for the action. In above example this element contains value SERVER showing that the signature was created using a server-held key.