The Signi API concept

• The principle of connection with Signi
• Variants of using Signi API
  • Submission of documents
  • Variants of recall
  • Transmission of results
  • 3. steps of the electronic legal transaction
  • Methods of authentication
  • Claimant vs. Parties
  • Existence of a Signi account
  • Signing scenarios
  • How to ensure connectivity

The principle of connection with Signi

The advantage of connecting applications and services with Signi is its simplicity, the whole process involves 3 steps.

Step 1 - Create background data 

• In your Application - ERP, CRM, DMS, website, internal application, etc. - the required data or documents about your client / partner / employee with whom you want to enter into a contract via the Signi API are entered - signature documents with signature coordinates or templates with parameters

Step 2 - Invoke verification 

• a) There is/is a function in your Application that, at the user's suggestion, passes the documents to Signi and invokes verification

• b) Signi has or prepares a function that will receive documents from your Application and then invoke verification

Step 3 - Receiving the results

• Information about the progress of document creation and verification is/is added to your Application

Variants of using Signi API

Submission of documents

We support two ways of passing documentation during integration:

• File transfer - A complete file in pdf, doc, docx, odt format is generated in your Application and sent to Signi API with other parameters for signature.

• Submitting the parameters for the template - Your Application will provide the metadata (headers, content of the individual contract completion fields, etc.) to complete the document template that is created and stored in Signi. This metadata along with other parameters are sent to the Signi API. 

Signi's default scope of services includes only the transmission of documents. The use of patterns is a paid extension.

Variants of recall

There are 4 ways to invoke signing from the integrated application:

• Distance signature

• Signature in the integrated application

• Sign as a work queue

• Signi via QR kód

Transmission of results

Callback

As part of the signature submission, three "webhook" URLs are provided for each result value:

• signed,

• rejected,

• expired

where one of them is called at the moment when the state occurs.

By continuously verifying the state

Sometimes webhooks can be difficult to implement in an integrated system.

Instead, it is possible to query the current status of a document periodically, or e.g. when opening the detail of a related record in the integrated system.

This can be useful e.g. for on-premise solutions that are not visible outside the corporate network, i.e. webhooks cannot be implemented.

For more information, see How do I get the result of a signature submission?

3. steps of the electronic legal transaction

Electronic legal transactions include 3 steps, namely remote identification, e-signature and archiving of electronic documents. All three steps are somehow reflected in the Signi API.

• Remote identification - as part of the signing process in Signi, a standard 2-factor authentication takes place via email and phone via a PIN sent in an SMS. Optionally, advanced variants of remote identification can be invoked via the API.

• Signing - files can be passed for signing or parameters for templates in Signi

• Archiving - Long-term archiving of documents can be provided directly in Signi using Signi Archiv. Alternatively, any electronic archive can be integrated with Signi - signed sealed documents are sent to Signi via callback webhooks, or the archive itself can discover documents suitable for archiving. The archive retrieves the documents, or can delete them from Signi via the API.

Methods of authentication

Single service account in Signi

• The simplest linking scenario, where the customer has only one account in Signi and it is only used for workspace creation and billing.

• None of the signers need to have an account in Signi. 

• Just use one API key for the entire workspace in Signi.

Accounts for Signi signers

• Signers must have an account in Signi and log into Signi each time they sign. 

• The advantage is that they can use pre-made signatures and can control access rights at the Signi level.

• One API key can still be used for the entire workspace in Signi.

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

Claimant vs. Parties

When signing and therefore transmitting documents via the API, a distinction must be made:

• Claimant - Is the creator of the document being signed and thus must have an account in Signi and the right to access the workspace/workspace in Signi. He/she may or may not be a party to the contract, e.g. with real estate agents. He receives notifications back about who signed the document, refused to sign, etc. He can cancel the document. He can see the new document in Sent Documents.  In the "Single Service Account" integration variant, this account is the creator of the document, but does not sign it.

• Counterparties - May or may not have an account in Signi. Can sign and reject the document. If he has an account in Signi, he sees the new document in Sent Documents (if he is also the drafter) or in Accepted Documents (if he is not the drafter).

When integrating via API, the simplest scenario is a Single Service Account (see above). In this case, the owner of the Signi workspace to which the document is sent for signature via the API is always automatically the drafter or author of the documents. He does not appear anywhere on the document, neither signs it nor approves it. The signatories or approvers, whether from within or outside the proponent's company, are the parties to the contract.

Existence of a Signi account

The person signing or approving the document may or may not have a Signi account. From the point of view of the API call, it doesn't matter, only the behavior of the service or its user interface before the document is displayed for signing differs.

So 2 situations can occur:

• the user does not have a Signi account - after clicking on the link in the notification SMS/email, the user is shown the document to sign straight away; only after signing is the user asked if they want to set up a Signi account,

• the user already has a Signi account - after clicking on the link in the notification SMS/email, the user is shown the Signi login screen and, after logging in, has access to the document to sign.

Signing scenarios

Although it does not seem so at first sight, there are several different variants of signing or approving a document, which can be combined for different parties involved:

Forms of consent:

• Signatory - has a signature on the document - with the understanding that there are multiple types of signatures
• Approves - only confirms agreement with the document, the signature is not visible

Order of signing

1. Signed first by the proponents and then by the counterparties

2. Depends on the order of signatories

How to ensure connectivity

Integration of Signi to another system can be achieved in various ways. Integration can be provided by:

• Signi team using Integromat integration service. For small complexity, the fee for using the integration/API includes the commissioning of the integration, for larger complexity, the fee includes a time and financial estimate of the scope of work.

• The system implementer or integration at the user in question via Integromat integration services, MS Power Automate / Flow, etc. or by directly calling the Signi API.  He/she will receive all documentation (see this site) and support from Signi.

• Internal IT user via Integromat integration services, MS Power Automate / Flow and similar or by direct API call to Signi.  He/she will receive all documentation (see this site) and support from Signi.