Manage third party integrations
SigningHub allows digital signatures to be easily integrated into any website/app through simple API calls. This is the smart way of adding Advanced Electronic Signatures into a web application that ensures a seamless experience for the end users. SigningHub also facilitates multi-tenancy that enables an organisation to define custom signing policies for their external users (i.e. clients, partners, contractors, etc.). The external users are those recipients who are not a part of your enterprise. They would be either part of another enterprise, an individual user, or a guest (non-SigningHub registered user), and you require them to sign documents within a tightly integrated app environment. This feature is usually requested by banks and financial institutions, who appreciate high-trust digital signing with tailor-made configurations to ensure a consistent signature style (appearance, details, etc.) for all users. For more details, visit Ascertia's Partner Portal for the Configuration Guide. You can integrate multiple web applications with your enterprise account. For details, see the Quick Integration guide and visit Ascertia's Partner Portal for API Guide. With respect to security, and embedded iframes used by SigningHub for tight integration, the Integrations set-up allows you to specify the trusted domains of your business application. When you supply input variables under "Allowed Domains" SigningHub will create the appropriate Internet headers when the iframe is called by the business application. These are X-Frame-Options ALLOW-FROM for older browsers and CSP: frame-ancestors Header for the latest versions of Chrome for example. If you do not specify a value it will allow all parent domains to add this integration page in an iFrame.
SigningHub supports workflows initiated via API and completed through the web interface, including embedded iFrame access. All associated outputs—such as the document processing report XML, workflow completion report, completed document, and workflow evidence report—will now be published to the configured webhook URL, regardless of whether the user actions are performed via API or the web.
The system will use the API key for all actions (e.g., Signed, Completed, etc.) when sending webhooks. If this API key exists in the workflow table, the system will always send webhooks to it, regardless of whether the document was signed using a different API key. If webhooks are not configured under the API integration section for this API key, the system will fall back to the enterprise-level webhook settings.
Integrate a (third-party) web application
Log in with your enterprise admin credentials.
Click "Configuration" in the left menu and click on "Integrations" in Settings options in Enterprise Configurations.
Click the "Add an Integration" button.
Configure the required information.
Click "Save changes".
Application
Client ID
Field to specify the client ID (application name) to be integrated, i.e. Salesforce App.
Call-back URL
In case of tight integration, specify the call-back URL where the users could be redirected when they close a document in the iframe.
However for loose integration, specify a dummy URL to generate a Client Secret. As the call-back URL will not be required in the app configuration.
Settings
Default Role For External Users
This field is related to multi-tenancy functionality, see visit Ascertia's Partner Portal for Configuration Guide. Select a default role for all those users who don't belong to this enterprise, to make them use your custom signature settings.
In this way, when your enterprise document is shared with an external user through this integrated app, and they (external user) also sign it through this integrated app, SigningHub will supersede their personal/ enterprise signature settings with the ones defined in this role at the time of signing.
The user roles can be managed from Enterprise Settings>Roles section.
Enable Scope Tokens
Enable this option to allow the use of scope tokens within integration applications, supporting a least-privilege security approach.
When this option is enabled, scope-based configurations become available, including 'Roles Allowed To Request Scope Tokens' and 'Application Permissions for Scope', allowing control over both impersonation scope and permitted actions when using scope tokens.
Disable this option to hide and restrict all scope-related configurations and actions, including token generation, related APIs, and the associated configuration fields.
Roles Allowed To Request Scope Tokens
This field is available only when Enable Scope Tokens is enabled.
Select the roles whose users can be impersonated when accessing the system via a scope token.
This setting controls which users a Business Application is allowed to act on behalf of when using scope tokens, supporting a least-privilege access model.
If no roles are selected, users from all roles can be impersonated.
Clicking on this field will display a drop-down containing all the configured roles of the enterprise. Multiple roles can be selected.
Application Permissions for Scope
This field is available only when Enable Scope Tokens is enabled.
Select the role that defines what actions can be performed using the scope token.
This role determines the permissions available to a Business Application when acting on behalf of enterprise users via scope tokens.
If no role is selected, all actions are allowed.
Clicking on this field will display a drop-down containing all the configured roles of the enterprise. Only a single role can be selected at a time.
Hide Documents From Recipients
This field is related to multi-tenancy functionality and is used to hide shared documents from external users.You can select any of the following options:
None – Documents are visible to all recipients. External users can view shared documents in their personal document listing.
First – Hides documents from only the first recipient. No notification email is sent to the first user; they can access the document only via a direct integration link. The document will not appear in their listing.
All – Hides documents from all recipients. No notification emails are sent, and documents are accessible only via direct integration links. Documents will not appear in recipients’ listings.
Allowed domains (separated by commas)
Specify the domain(s) allowed to embed the Document Viewer and SmartForms within an iframe. Leaving this field blank allows embedding from all domains.
Collapse the document viewer's sidebar panel by default
Enable this option to open the Document Viewer within the tight integration screen with the right sidebar panel collapsed by default. Users can expand it manually when needed.
Disable this option to open the Document Viewer with the sidebar visible by default.
Lock the document viewer's sidebar panel by default
Enable this option to completely hide the right sidebar panel and prevent users from expanding it.
Disable this option to allow sidebar visibility based on the “Collapse the document viewer’s sidebar panel by default” setting.
Automatically redirect to the callback URL after task completion
Enable this option to automatically redirect users to the callback URL after completing signatures or in-person signatures.
If disabled, users remain on the Document Viewer screen after completing their task unless they manually close it.
This option will only redirect users to the call-back URL automatically if the "Automatically proceed with workflow upon completion of mandatory actions by signer" is enabled, under "Enterprise Settings>Roles>Document Settings".
Webhooks
Webhooks
Specify a callback URL where SigningHub could send the HTTP POST update of each workflow of the integrated application. This is useful in those cases where all the configured recipients don't necessarily need to process a document package to complete their workflow.
The workflow completion can be controlled by an external business application that could decide on need basis, whether to mark a document as complete or not after every major processing activity performed on it.
When a URL is provided, this POST request provides the information of each workflow like:
Document Package
Document
Recipient
Action performed by the recipient on a document
State of the Workflow
Next signatories
Type of Workflow
State of the document
Errors (Signing) SigningHub publishes an error webhook at the specified server URL for Go>Sign performed using the ADSS Server. These include:
The error that occurred when RUT is not configured.
The errors that occurred in Go>Sign Service and Go>Sign JS.
Enable the below for when you want the system to send a document processing report (XML) of the integrated application to the provided server address.
For document actions, when:
Shared
Signed
Declined
Reviewed
Meeting Host
Edited
Sent a Copy
Reminded
Recalled
Completed
Evidence Report is generated
Enterprise document is deleted
For user actions, when:
Registered
Updated
Deleted
For errors, when:
Signing
The business application can then use the respective SigningHub API call to inform SigningHub that a workflow is complete and hence no need to send this document to the remaining recipients. Also while marking a workflow as complete, if any recipient of it has got this document in the "Pending" state, then SigningHub will delete the document from their inbox.
Irrespective of the enterprise settings or the integration settings, the document processing report (XML) will only be sent if the "Send the document processing report (XML)" option is allowed, in post processing. By default, the "Send the document processing report (XML)" option will be allowed for all new workflows.
Workflow Completion
Workflow Completion
This area allows you to configure report routing of the integrated application upon workflow completion.
Send the workflow completion report
Enable to automatically post the workflow reports of the integrated application (in XML format) to the configured address when the workflow completes. This applies to all users within your integrated application. When enabled, the "Server URL" and "Add the completed document" fields are displayed.
Server URL
Enable to specify the web server URL where the workflow completion reports of the integrated application are required to send.
SigningHub gives you an option to publish Workflow Completion Reports along with the completed documents to a specific web server/URL. This configuration is at the integration level. The metadata and signed documents allow third party business applications to closely integrate with SigningHub and prevent the need to poll to check for complete status. For further details refer to "Publish Workflow Completion Report".
Add the completed document
Enable "Add the completed document" to receive the completed document along with the workflow completion report.
Add the workflow evidence report (WER)
Enable "Add the workflow evidence report (WER)" to receive the workflow evidence report along with the workflow completion report; else, leave empty.
In case the specified URL is invalid or inaccessible, SigningHub will send an email to the document owner upon workflow completion.
If the document package contains a single document, its document type will be PDF in the workflow completion report (XML).
If the document package contains multiple documents, their document type will be ZIP in the workflow completion report (XML).
If both, the "Add the completed document" and the "Add the workflow evidence report (WER) in the report" have been enabled, their document type will be ZIP in the workflow completion report (XML).
The "Add the workflow evidence report (WER)" will only appear if the "Detailed with Workflow Evidence Report" option has been enabled against "Workflow Evidence Recording" in the user's service plan.
If only the "Add workflow evidence report (WER)" is enabled, its document type will be PDF in the workflow completion report (XML).
If both, the "Add the completed document" and the "Add the workflow evidence report (WER)" have been enabled, their document type will be ZIP in the workflow completion report (XML).
The publishing behaviour of the system with respect to whether the webhooks and the workflow completion report have been configured in the document owner's enterprise settings, and in the integration settings of the recipient's enterprise, is as below:
Webhooks and the Workflow Completion Report are configured in the document owner's enterprise settings
Webhooks and the Workflow Completion Report are configured in the integration settings of the recipient's enterprise
System Behavior Publishing Webhooks and the Workflow Completion Report
Configured
Configured
The integration settings of the recipient's enterprise will be followed.
The enterprise settings of the document owner's enterprise will be followed.
Configured
Not Configured
The enterprise settings of the document owner's enterprise will be followed.
Not Configured
Configured
The integration settings of the recipient's enterprise will be followed.
Not Configured
Not Configured
The system will not publish the Webhooks and the Workflow Completion Report.
Edit an integration instance
Login with your enterprise admin credentials.
Click "Configuration" in left menu and click on "Integrations" in Settings options in Enterprise Configurations.
Select the desired instance and click "Edit" in the right panel.
Configure the required changes in the relevant section.
Click "Save changes".
Delete an integration instance
Login with your enterprise admin credentials.
Click "Configuration" in left menu and click on "Integrations" in Settings options in Enterprise Configurations.
Select the desired instance and click "Remove" in the right panel.
Click "Delete" in the confirmation dialogue.
In order to use the Single sign-on (SSO) facility in SigningHub, the "Default Authentication Method" must either be Microsoft Active Directory, Microsoft ADFS, SalesForce, or Microsoft Office 365.
The external users are those document recipients who are not a part of your enterprise. They would either be part of another enterprise, an individual user, or guest non-SigningHub registered users, and you require them to sign documents within a tightly integrated app environment.
The availability of "Integrations" feature is subject to your subscribed service plan. If you cannot find this option in your account, upgrade your service plan.
ClientID cannot be set as 'MobileSDK' or 'MSOfficeApp', since it has been preoccupied by the SigningHub application for it's Mobile version and MS Office App.
Last updated
Was this helpful?