The principle of connecting to Signi

The advantage of connecting applications and services to Signi is in its simplicity; the entire process is a matter of 3 steps.

Step 1 - Creating underlying data 

• The required data or documents about the client/partner/employee you want to sign a contract with via API Signi - documents for signing with the coordinates of signatures or specimens with parameters - are submitted in your Application - ERP, CRM, DMS, website, in-house application, etc.

Step 2 - Invoking verification 

• There is a function in your Application (or a function is added) which transfers supporting documents to Signi and invokes verification at the instigation of the user.

• Signi has, or is preparing, a function that will take supporting documents from your Application and subsequently invokes verification.

Step 3 - Receiving the outcome

• Information about the process of creating and verifying documents is found in/is added to your Application.

Alternatives of using Signi API

Transferring supporting documents

We support two methods of transferring supporting documents during integration:

• Transferring files - A complete file is generated in your Application in pdf, doc, docx, or odt format and is sent with the other parameters to API Signi for signing.

• Transferring parameters for a template - Your Application provides metadata (headers, content of individual fill-in fields of a contract, etc.) so that the template document can be filled in, and then created and saved in the Signi application. These metadata and other parameters are sent to API Signi. More about templates here.

In their base form, Signi services only involve transferring documents. The use of templates is a paid add-on.

Authentication

A single service account in Signi

• This is the simplest connection scenario, when the customer has only one account in Signi, used only to create workspace and for invoicing.

• None of the signatories need have an account in Signi. 

• It is enough to use one API key for the entire workspace in Signi.

Accounts for signatories in Signi

• Signatories must have an account in Signi and log into Signi for each and every signature. 

• The advantage is that they can use pre-prepared signatures and that it is possible to govern access rights at Signi level.

• It is still possible to use one API key for the entire workspace in Signi. 

We are also preparing the option of personal API keys or authentication via Oauth2, etc.

Proposer versus contracting parties

The following must be differentiated when signing, and therefore transferring, supporting documents via API:

• The proposer - Is the creator of the signed document, and must therefore have an account in Signi. Might be, but need not be, a contracting party - for example, in the case of estate agents. Receives notification about who has signed the document, who has refused to sign, etc. May cancel the document. Sees a new document in Sent documents.  In the case of “Single service account” integration, it is this account that is the document creator, but does not sign the document.

• Contracting party - May, but need not, have an account in Signi. May sign and reject a document. If having an account in Signi, sees a new document in Sent documents (if simultaneously the proposer) or in Received documents (if not the proposer).

The simplest scenario in the case of integration through API is the Single service account (see above). In this case the proposer, or author, of documents is automatically the owner of the Signi workspace to which a document is sent for signing via API. He/she never figures on the document, does not sign it, does not even approve it. The signatories or approvers, whether from the proposer’s company or elsewhere, are the contracting parties.

The existence of an account for the Signi service

The person signing, or approving, a document may have, but need not have, an account in Signi. This is not important from the perspective of calling API; only the behavior of the service differs, or more specifically its user interface before displaying a document for signing.
Two situations might therefore occur:  

• the user does not have an account in Signi - the document to be signed is displayed to the user after clicking on the link in the notification SMS/e-mail. After signing the document, the user is asked whether he/she would like to set up an account in Signi;

• the user already has an account in Signi - the Signi login screen is displayed to the user after clicking on the link in the notification SMS/e-mail. After logging in, the user has access to the document to be signed.

Signing scenarios

Although it might not appear so at first glance, there are actually several ways of signing, or approving, a document. What is more, these can be combined for the different parties involved:

Forms of expressing consent:

Signs - has a signature on the document
Approves - merely confirms agreement with the document, signature not visible

The order of signing

1. Proposers sign first, then the counterparties

2. Depends on the order of signatories

Access to pages for signing

There are two basic ways:

• Remote signing - After calling the end point for signing a document or template, Signi sends the signatories e-mail notification with a link to the pages to be signed. If a telephone number is specified, SMS notification can also be sent. This is the standard way of sending a document for signing via Signi user interface.

• Signing on one device - The end point for signing the document returns the URL for the signatures of individual signatories, see How do I receive the outcome of transferring supporting documents for signing and the integrated application displays the corresponding links, framework, etc. for the signature of individual persons. Note that when there are multiple signatories, they must all have their own space for signing. This is the parallel of signing on one device via Signi user interface.

Transferring outcomes

Call-back

Three URL addresses are also involved in transferring supporting documents for signing, what are known as “webhooks” for each outcome value:

• signed

• rejected

• expired

in that one of these is invoked at such time as the situation in question arises.

Regularly checking status

Sometimes it is difficult to implement webhooks in the integrated system.

Instead of this, it is possible to ask about the current status of a document on a periodic basis, or for example when opening the details of the associated record in the integrated system.

This might be useful, for example, for solutions operated on-premise which are not visible outside the company network; i.e. the webhook cannot be implemented.

For more see How do I receive the outcome of transferring supporting documents for signing

How to ensure connection

Integrating Signi into another system can be done in several ways. Integration can be handled by:

• The Signi Team with the use of the integration service Integromat. If the process is not demanding, putting integration into service is included in the fee for the use of integration/API, if it is more demanding there is a time and financial estimate of the amount of work in the fee.

• Implementer of the system or integration at the relevant user via the integration service Integromat , MS Power Automate / Flow and the like, or by way of calling API Signi direct.  Receives all supporting documents and support for this from Signi.

• Internal IT user via the integration service Integromat , MS Power Automate / Flow and the like, or by way of calling API Signi direct.  Receives all supporting documents and support for this from Signi.