Variants of signing by representatives of an organization using Signi
When integrating Signi, it allows for several options for signing by employees of the organisation using Signi, typically statutory officers, authorised dealers, etc.:
A - The organization's officers do not have an account in Signi, they just sign through it like counterparties.
B - Employees of the organization have an account in Signi, their signatures can be entered automatically.
C - The signature of the organization's employee is already inserted e.g. in graphic form in the document inserted in Signi, Signi only provides the signature of the counterparties.
The key fact is that every document in Signi must have a unique document author.
In the script A
The advantage of the scenario is its simplicity to get up and running. The disadvantage is that the signing staff of the organization, typically the statutory officers, must sign or approve each individual document.
The organization's officers don't need to have a Signi account, they sign just like the counterparties - they get an email asking them to sign, open the signature page from that email, and sign or approve the document.
When integrating, you can specify the email of the workspace/workspace founder on Signi as the proposer/author of the document, where the document is being sent, and say that he/she will only approve the document (via the API automatically).
Organization and counterparty staff can sign documents (contracts) or only approve them (e.g. General Terms and Conditions).
The signing scenario passed through the API will then contain, for example, the following:
{
"settings": {
"signing_order": one_at_a_time",
}
{
"people": [
{
"is_proposer": true,
"email": "zakladatelworkspace@firmanavrhujicidokument.cz",
"contract_role": "approve"
},
{
"is_proposer": false,
"party_order": 1,
"email": "podepisujiciobchodnik@firmanavrhujicidokument.cz",
"contract_role": "sign"
},
{
"is_proposer": false,
"party_order": 2,
"email": "podepisujícizakazník@firmaprotistrana.cz",
"contract_role": "sign"
}
],In scenario B
Pokud pracovníci organizace:
have created an account on Signi,
have been invited by the workspace owner to the workspace with signing rights set and have accepted the invitation,
they have pre-set their signature in their account, and
automatic signing by the proposer is enabled on the workspace/workspace, including specifying the location of the signature, e.g. "Prague",
their signature can be automatically inserted into the document. According to EIDAS this is fine, the signing is done in a controlled Signi environment that ensures the signature is inextricably attached to the corresponding documents, and the calling application (yours) has authenticated and authorized the person to create, sign and forward the document to other counterparties for signature.
The signing scenario passed through the API will then contain, for example, as follows , the author / drafter of the document whose signature can be automatically inserted under the conditions above is podepisujiciobchodnik@firmanavrhujicidokument.cz:
{
"settings": {
"signing_order": "one_at_a_time",
"autosign_proposers": "V Praze"
},
"people": [
{
"is_proposer": true,
"email": "podepisujiciobchodnik@firmanavrhujicidokument.cz",
"contract_role": "sign"
},
{
"is_proposer": false,
"party_order": 1,
"email": "podepisujícizakazník@firmaprotistrana.cz",
"contract_role": "sign"
}
],Any workspace user with signature rights as the author/designer of a document can be signed automatically. However, they must sign first before counterparties. The API key of the workspace founder can be used to connect to Signi. Thus, the 3 workers/s in HR can be automatically signed on "their" documents, only when the API call is made their emails are listed as the emails of the proposer i.e. "is_proposer": true for the person in the first position of the signature scenario in the Person field.
In scenario C
In terms of the EU eIDAS Directive, a signature in graphical form embedded in a document can be considered as an electronic signature at the plaintext level. This is analogous to a situation where the signature of the responsible bank manager is placed in a letter from the bank, it is not assumed that the employee would sign thousands of documents.
It makes sense in cases where there is a low risk of litigation or that the opposing party will dispute the claimant's signature.
In that case, only the counterparty signs, the claimant's representative, who is the workspace founder, automatically approves the document.
{
"settings": {
"signing_order": one_at_a_time",
}
{
"people": [
{
"is_proposer": true,
"email": "zakladatelworkspace@firmanavrhujicidokument.cz",
"contract_role": "approve"
},
{
"is_proposer": false,
"party_order": 2,
"email": "podepisujícizakazník@firmaprotistrana.cz",
"contract_role": "sign"
}
],The "contract_role = sign / approve" option tells whether there will be a physical signature on the document, or whether a person should just approve it.
- If a signature is to be seen somewhere on the document, for example on a contract, "sign" is called.
- If someone is just supposed to approve the document, for example the General Terms and Conditions, it is called with "approve".
How is the binding between the user of the integrated application and the workspace and the user in Signi captured
The integrated application user - Signi workspace relationship
Workspace in Signi is used for storing documents, multiple people can be assigned to its team. In turn, multiple people can have access to multiple workspaces.
When a Signi API call is made, an API key is used for authentication, i.e., it clearly specifies which workspace the document will be stored in. For more information, see Generating an API key.
If they are registered in your application:
a) only users - an API key must be provided for each user.
b) also companies or branches of users - to which individual users storing documents in one workspace in Signi are then assigned, the Signi API key can be listed for the company or branch and used when calling all "its" users
Binding integrated application users - Signi users
In account A mode, see above, it's easier. You just need to have
the email of the main customer account in Signi for all users,
for a company/affiliate, the email of the main customer account in Signi.
In account B mode, all users need to have their email entered to log into Signi.
Why isn't the Signi API strictly RestAPI?
Signi is integrated with various mature applications.
This is reflected in the current form of the API, which can be called "Essential" and can easily be used even in a basic call from a simple web site to a PHP or CURL utility over HTTP.
PREPARING: A parallel version of the fundamental RestAPI, where for example binary files are transcoded into a text string.
How to test Signi behavior for unregistered users?
Signi behaves differently for those who are and are not registered in Signi. For the former, Signi requires them to be logged into Signi to sign a document. Documents delivered to them for signature are then accessible in their private workspace. The latter are offered anonymous unique pages for identification and signatures.
For testing Signi for unregistered users, the following is useful:
use of emails:
If you use Google email accounts, you can use their feature where emails sent to something@yourcompany.com will also arrive in your somethingelse@yourcompany.com inbox. If you send a document for signature to a Signi non-registered signer jarda.ripa+test@signi.com, notification emails will arrive in your existing jarda.ripa@signi.com mailbox, which is the address under which the Signi account is created.
In other cases, it makes sense to set up a company email group unregisteredinsigni@company.com, include all Signi testers in it, and use that email as the address of the Signi non-signatory.
invoke the counterparty signing links:
If you are logged in to Signi as a proponent in your web browser, you need to open the signing links in an anonymous window, because Signi otherwise assumes that you want to sign the document as a proponent, i.e. the counterparty link is inaccessible to you. This will result in an invalid link error.
- Tip: To test counterpart signatures, it is possible to shorten the testing by not waiting for the incoming email, but using the link available in the document detail, which you can copy using the copy icon.
The first is signed by the claimant and the second by the counterparty, the dates of the specimen are filled in
{
"contract_name":"document name - nonmandatory",
"number": "document number - nonmandatory",
"locale": "cs",
"settings": {
"signing_order": "proposers_before_counterparties",
"autosign_proposers": "V Praze"
},
"people": [
{
"is_proposer": true,
"email": "demo@signi.com",
"contract_role": "sign"
},
{
"is_proposer": false,
"party_order": 1,
"email": "demo+API@signi.com",
"contract_role": "sign",
"person_type": "nature",
"first_name": "John",
"last_name": "Doe#2"
}
],
"template": {
"id": "7v1",
"parameters": [
{"id": "112", "value": "Hnutí za digitalní revoluci"},
{"id": "131", "value": "Chci"},
{"id": "411", "value": "V šíření zpráv"},
{"id": "421","value": "27.5.2021"},
{"id": "431","value": "v Praze"}
]
}
}Automatically approved by the proponent's attorney and then signed by the opposing party, signed on file, signatures at the end in the Signature Sheet.
Both the representative of the claimant and the counterparty sign at the same time, the signature file is signed, the positions of the signatures are determined by the fields for the placement of signatures in the document.
{
"contract_name": "Document with placeholders",
"number": "2022000001",
"locale": "cs",
"settings": {
"signing_order": "all_at_once"
},
"people": [
{
"is_proposer": true,
"email": "demo@signi.com",
"contract_role": "sign",
"positions": [
{
"anchor": "signi-signature-00"
}
]
},
{
"is_proposer": false,
"email": "zakaznik@seznam.cz",
"contract_role": "sign",
"person_type": "nature",
"first_name": "John",
"last_name": "Doe#2",
"positions": [
{
"anchor": "signi-signature-02"
}
]
}
],
"file": "uploaded_file_key"
}Both parties sign via BankID Sign
- JSON see Signing with BankID
Broker and two customers sign form via BankID
{
"locale": "cs",
"settings": {
"signing_order": "all_at_once"
},
"people": [
{
"is_proposer": true,
"email": "registered.broker@test.cz",
"contract_role": "sign_bank_id_sign",
"positions": [
{"x": 20, "y": 60, "page": 0}
]
},
{
"is_proposer": false,
"email": "customer1@test.cz",
"contract_role": "sign_bank_id_sign",
"person_type": "nature",
"first_name": "John",
"last_name": "Customer#1",
"positions": [
{"x": 20, "y": 70, "page": 0}
]
},
{
"is_proposer": false,
"email": "customer2@test.com",
"contract_role": "sign_bank_id_sign",
"person_type": "nature",
"first_name": "John",
"last_name": "Customer#2",
"positions": [
{"x": 20, "y": 80, "page": 0}
]
}
],
"file": "uploaded_file_key",
"attachments": []
}Signed by an unregistered broker and an unregistered client via BankID Sign e.g. when they prepare a contract in the main system and offer it for signature directly in the main system
{
"locale": "cs",
"settings": {
"signing_order": "all_at_once",
"autosign_proposers": true
},
"people": [
{
"is_proposer": true,
"email": "registered.bot@test.cz",
"contract_role": "approve"
},
{
"is_proposer": false,
"email": "broker@test.cz",
"person_type": "nature",
"first_name": "John",
"last_name": "Broker",
"contract_role": "sign_bank_id_sign",
"positions": [
{"x": 40, "y": 70, "page": 0}
]
},
{
"is_proposer": false,
"email": "customer1@test.cz",
"contract_role": "sign_bank_id_sign",
"person_type": "nature",
"first_name": "John",
"last_name": "Customer#1",
"positions": [
{"x": 20, "y": 70, "page": 0}
]
}
],
"file": "uploaded_file_key",
"attachments": []
}The main system generates a PDF already signed with the certificate and the client signs via BankID Sign
{
"locale": "cs",
"settings": {
"signing_order": "all_at_once",
"autosign_proposers": true
},
"people": [
{
"is_proposer": true,
"email": "registered.bot@test.cz",
"contract_role": "approve"
},
{
"is_proposer": false,
"email": "customer1@test.cz",
"contract_role": "sign_bank_id_sign",
"person_type": "nature",
"first_name": "John",
"last_name": "Customer#1",
"positions": [
{"x": 20, "y": 70, "page": 0}
]
}
],
"file": "uploaded_file_key",
"attachments": []
}Sending documents in Work in Progress / Draft status
The integrated application sends the document to Signi in draft state, where it appears in the Work in progress state, here it can be edited and sent.
Examples of use
{
"locale": "cs",
"state": "draft",
"settings": {
"signing_order": "all_at_once"
},
"people": [
{
"is_proposer": true,
"email": "registered.broker@test.cz",
"contract_role": "sign_bank_id_sign",
"positions": [
{"x": 30, "y": 70, "page": 0}
]
},
{
"is_proposer": false,
"email": "customer1@test.cz",
"contract_role": "sign_bank_id_sign",
"person_type": "nature",
"first_name": "John",
"last_name": "Customer#1",
"positions": [
{"x": 20, "y": 70, "page": 0}
]
}
],
"file": "uploaded_file_key",
"attachments": []
}Signing the document with control before the signature of the statutory representatives
See also Script Library >Signing a document with control before the signature of the statutory representatives
{
"contract_name": "S kontrolou dokumentu před odesláním, záleží na pořadí",
"state": "pending",
"settings": {
"signing_order": "one_at_a_time"
},
"template": {
"parameters": [
{"id": "Zadost.Name", "value": "000477"},
{"id": "Zadost.Organizace__r.Name", "value": "Nadace TEST"},
{"id": "Zadost.Organizace__r.BillingStreet","value": "Zelenecska 954/24b"},
{"id": "Zadost.Organizace__r.BillingCity","value": "Prague 9"},
{"id": "Zadost.Organizace__r.BillingPostalCode", "value": "19800"},
{"id": "Zadost.Organizace__r.Clouderia_Reg__ICO__c","value": "10203058"},
{"id": "Zadost.Organizace__r.Typ_rejstriku__c", "value": "Nadační rejstřík"},
{"id": "Zadost.Organizace__r.Clouderia_Reg__Court_Name__c","value": "soud Praha 10"},
{"id": "Zadost.Organizace__r.Clouderia_Reg__Court_File_Number__c","value": "35"},
{"id": "1.1 varianta 1", "value": "hide"},
{"id": "1.1 varianta 2", "value": "show"}
],
"id": "1085"
},
"people": [
{
"contract_role": "approve",
"email": "demo+CZzamestnanec4@signi.com",
"is_proposer": true,
"last_name": "Kontrolující za navrhovatele s právem přístupu do workspace"
},
{
"contract_role": "sign",
"email": "demo+CZzamestnanec1@signi.com",
"is_proposer": true,
"last_name": "Podepisující za navrhovatele s právem přístupu do workspace"
},
{
"last_name": "Jenik",
"first_name": "Ales",
"person_type": "nature",
"contract_role": "sign",
"email": "demo+protistrana1@signi.com",
"is_proposer": false
}
]
}
The integrated application returns a URL that the current user can approve in PipeDrive. The page opened from the link can be used to approve or sign the document.
Rejection
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article