...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Výhodou propojení aplikací a služeb se Signi je jeho jednoduchost, celý proces zahrnuje 3 kroky.
...
Krok 1 - Vytvoření podkladových údajů
...
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, webu, interní aplikaci apod. - jsou zadány požadované údaje či dokumenty o vašem klientovi / partnerovi / zaměstnanci, se kterým chcete uzavřít smlouvu přes API Signi - dokumenty k podpisu se souřadnicemi podpisů anebo vzorů s parametry
Krok 2 - Vyvolání ověření
ve vaší Aplikaci je/přidá se funkce, která na podnět uživatele předá podklady do Signi a vyvolá ověření
Signi má nebo připraví funkci, která bude přebírat podklady z vaší Aplikace a následně vyvolá ověření
Krok 3 - Převzetí výsledků
Ve vaší Aplikaci je/ se přidá informace o průběhu vytvoření a ověření dokumentů
Varianty použití Signi API
Předání podkladů
Podporujeme dva způsoby předávání podkladů při integraci:
Předání souborů - Ve vaší Aplikaci je vygenerován kompletní soubor ve formátu 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, odt, který je s ostatními parametry odeslán do API Signi k podpisu.
Předání parametrů pro vzor - Vaše Aplikace poskytne metadata (hlavičky, obsah jednotlivých doplňovacích polí smlouvy apod.) pro doplnění vzoru dokumentu, který je vytvořen a uložen v aplikaci Signi. Tato metadata společně s ostatními parametry jsou odeslány do API Signi. Více o vzorech zde.
Výchozí rozsah služeb Signi zahrnuje pouze předávání dokumentů. Použití vzorů je placené rozšíření.
Autentikace
Jediný servisní účet v Signi
Nejjednodušší scénář propojení, kdy účet v Signi má zákazník pouze jeden a slouží pouze pro vytvoření workspace a fakturaci.
Žádný z podepisujících nemusí mít účet v Signi.
Stačí použít jeden API klíč k celému pracovnímu prostoru v Signi.
Účty pro podepisující v Signi
Podepisující musí mít účet v Signi a při každém podpisu se přihlašují do Signi .
Výhoda je, že mohou použít předpřipravené podpisy a lze řídit práva přístupu na úrovni Signi.
Lze stále používat jeden API klíč k celému pracovnímu prostoru v Signi.
Připravujeme i možnost osobních API klíčů či autentikaci přes Oauth2 apod.
Navrhovatel vs. smluvní strany
Při podepisování a tedy i předávání podkladů přes API je třeba odlišit:
Navrhovatel - Je tvůrce podepisovaného dokumentu a tedy musí mít účet v Signi. Může a nemusí být smluvní stranou, např. u realitních makléřů. Chodí mu zpět notifikace o tom, kdo dokument podepsal, odmítl podepsat apod. Může dokument zrušit. Nový dokument vidí v Odeslaných dokumentech. Ve variantě integrace "Jediný servisní účet" je právě tento účet tvůrcem dokumentu, který ale nepodepisuje.
Smluvní strana - Může a nemusí mít účet v Signi. Dokument může podepsat a odmítnout. Pokud má účet v Signi, nový dokument vidí v Odeslaných dokumentech (pokud je zároveň navrhovatelem), nebo v Přijatých dokumentech (pokud není navrhovatelem).
Při integraci přes API je nejjednodušší scénář Jediný servisní účet (viz výše). V tomto případě je automaticky navrhovatelem resp. autorem dokumentů vždy vlastník pracovního prostoru Signi, do kterého se posílá dokument k podpisu přes API. Ten na dokumentu nikde nefiguruje, ani ho nepodepisuje, ani ho neschvaluje. Podepisující či schvalovatelé, ať z firmy navrhovatele či mimo ni jsou smluvními stranami.
Existence účtu na službě Signi
Člověk podepisující, resp. schvalující dokument může a nemusí mít účet v Signi. Z hlediska volání API je to jedno, liší se pouze chování služby, resp. její uživatelské rozhraní před zobrazením dokumentu k podpisu.
Mohou tedy nastat 2 situace:
uživatel nemá účet v Signi - po kliknutí na link v notifikační SMS / e-mailu se mu ukáže rovnou dokument k podepsání; až po podpisu se mu nabídne, zda si chce zřídit účet v Signi,
uživatel již má účet v Signi - po kliknutí na link v notifikační SMS / e-mailu se mu ukáže přihlašovací obrazovka Signi a po přihlášení má přístup k dokumentu k podepsání.
Scénáře podepisování
Ač se to na první pohled nezdá, existuje více různých variant podepisování, resp. schvalování dokumentu, které lze navíc kombinovat pro různé zúčastněné strany:
Formy vyjádření souhlasu:
Podepisuje - má podpis na dokumentu
Schvaluje - jen potvrdí souhlas s dokumentem, podpis není vidět
Pořadí podepisování
Podepisují nejdříve navrhovatelé a pak protistrany
Záleží na pořadí podepisujících
Přístup ke stránkám pro podepsání
Jsou dvě základní cesty :
Distanční podepsání - Podepisujícím po zavolání end pointu pro podpis dokumentuči vzoru Signi odesílá emailová notifikace s odkazem na stránky pro podepsání. Pokud je uvedeno tel číslo, může odcházet i SMS notifikace. je to obdoba standardního odeslání dokumentu k podpisu přes uživatelské rozhraní Signi.
Podpis na jednom zařízení - End point pro podpis dokumentu vrací URL pro podpis jednotlivých podepisujících viz Jak získám výsledek předání podkladů pro podpis a integrovaná aplikace zobrazí odpovídající odkazy, rámce apod. pro podpis jednotlivých osob. Pozor, pokud je podepisujících více, musí mít všechni svůj prostor k podpisu. Je to obdoba podpisu na jednom zařízení přes uživatelské rozhraní Signi.
Předání výsledků
Zpětným voláním
Součástí předávání podkladů pro podpis jsou i tři URL adresy tzv. “webhooků” pro každou hodnotu výsledku:
podepsáno - signed,
odmítnuto - rejected,
neověřeno - expired
kdy jeden z nich se vyvolá v okamžiku, kdy daný stav nastane.
Průběžným ověřováním stavu
Někdy lze webhooky v integrovaném systému obtížně implementovat.
Místo toho je možné se dotazovat na aktuální stav dokumentu, a to periodicky, anebo např. při otevření detailu souvisejícího záznamu v integrovaném systému.
Toto se může hodit např. pro on-premise provozovaná řešení, která nejsou viditelná mimo firemní síť, tj. webhook nelze zrealizovat.
Více viz Jak získám výsledek předání podkladů pro podpis
Jak zajistit propojení
Integrace Signi na jiný systém může být zajištěna různými způsoby. Integraci může zajistit:
Tým Signi s využitím integrační služby Integromat. Při malé náročnosti je v poplatku za využití integrace/API i zprovoznění integrace, při větší náročnosti je v poplatku časový a finanční odhad rozsahu prací.
Implementátor systému či integrací u daného uživatele přes integrační služby Integromat , MS Power Automate / Flow a podobně nebo přímým voláním API Signi. Dostane k tomu od Signi všechny podklady (viz tyto stránky) a podporu.
Interní IT uživatel přes integrační služby Integromat , MS Power Automate / Flow a podobně nebo přímým voláním API Signi. Dostane k tomu od Signi všechny podklady (viz tyto stránky) a podporuor 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
Proposers sign first, then the counterparties
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.