Envelope Management

Does the envelope initiated by OpenAPI support preview in the draft state?

Envelopes created by uploading local files via OpenAPI do not support preview in draft status. To preview an envelope, please create it using an OpenAPI template and retrieve the preview file by calling the File Composition Task Details API (/esignglobal/v1/templates/renderTask).

The OpenAPI interface cannot query envelopes initiated on the web end.

Yes. Currently, the OpenAPI interface doesn't support querying envelopes initiated on the web end. However, the web end can query envelopes initiated by OpenAPI.

After the user cancels the signing and starts again, can the taskId, fileKey and envelopeId be reused?

The `fileKey` can be reused. The purpose of `taskId` is to retrieve the file, and since files can be reused, there's no need to create a new one. However, `envelopeId` cannot be reused.

Does eSignGlobal support automatic (silent) signing for signatures and seals?

eSignGlobal supports automatic (silent) triggering of the document signing process by seals, without the need for manual intervention. When enterprises are dealing with a large number of standardized contracts (such as employee onboarding contracts, supplier cooperation agreements, etc.), they can complete the signing of numerous contracts at one time through silent signing, saving a significant amount of time and manpower. Regarding personal signatures, to ensure the compliance of the evidence chain, personal signatures need to be signed manually and do not support automatic (silent) signing. For the OpenAPI one-step initiation or distributed initiation interfaces, setting the "autoSign" bit to "true" means silent signing. For more details, please refer to the following interfaces.

        {
            "userEmail": "fengnian@tsign.cn",
            "userFirstName": "",
            "userLastName": "fengnian",
            "signOrder": 2,
            "autoSign": true, //静默签只支持图章，静默签需要传autoSign和stampId(图章ID的值)
            "signDateConfigs": [
                {
                    "posX": 200,
                    "posY": 765,
                    "pageNo": "1",
                    "signDateFormat": "yyyy-MM-dd"
                }
            ],
            "sealInfos": [
                {
                    "fileKey": "xxxxx",
                    "signConfigs": [
                        {
                            "fieldType": "stamp",
                            "posX": "455.61234",
                            "posY": "375.12186",
                            "pageNo": "1",
                            "width": 164,
                            "height": 162,
                            "stampId": "xxxxxxx"
                        }
                    ]
                }
            ]
        }

Does OpenAPI support initiating signing with specified seals?

The following is a detailed answer to the question of whether OpenAPI supports initiating signing with specified seals: Regarding the regular signing initiation via OpenAPI: Under normal circumstances, OpenAPI does not support initiating signing operations with specified seals. Regarding initiating signing with specified seals during automatic (silent) signing via OpenAPI: When using OpenAPI for automatic (silent) signing, it is possible to initiate signing with specified seals. However, certain conditions need to be met. Specifically, two key parameters need to be passed in the relevant operations. First, set the "autoSign" parameter to "true" to indicate that it is an automatic (silent) signing operation mode. Second, the "stampId" parameter needs to be passed in, and this parameter corresponds to the unique identifier of the specific seal to be used. Only by passing these two parameters simultaneously can the function of initiating signing with the specified seal be achieved. Regarding the preconditions for signatories to use seals: If a signatory wants to use the seals of the company or department for signing, the administrator of the workspace needs to create the corresponding seals in advance. Only after the administrator has completed the seal creation work can the signatory have available seals to complete the signing process when conducting subsequent signing operations. It is hoped that the above content can help you clearly understand the relevant rules and operational requirements of OpenAPI regarding initiating signing with specified seals.

Does the signatory support using the seals of the company or department?

If the signatory needs to use the seals of the company or department, the following two conditions need to be met: 1) It is necessary to first check whether the signatory and the initiator are under the same tenant. If not, the signatory can be invited to become a member under the same tenant in the member list and obtain the consent of the invitee.

2) It is necessary to check whether there are already created seals under this tenant. If there are no seals, the administrator needs to create them so that the signatory can choose to sign with the seals when signing.

Does OpenAPI-initiated silent signing support silent signing by people who are not under the same tenant? Otherwise, an error message will be reported: {"code":"120132","message":"The participant and initiator of the silent sign are not the same tenant"}

Regarding initiating silent signing via OpenAPI, it does not support personnel who are not under the same tenant to conduct silent signing. If the signatory has an unregistered account or the account is not under the same tenant as that of the initiator, then when initiating silent signing, the operation will fail and an error message will appear. For example, a prompt like {"code":"120132","message":"The participant and initiator of the silent sign are not the same tenant"} will be reported. If you hope to be able to initiate silent signing smoothly, you can invite the signatory to become a member under the same tenant through the member list and obtain the consent of the invitee. Only when the initiator and the signatory are under the same tenant can silent signing be initiated normally. For specific operation details, you can view the relevant schematic diagrams.

What's the difference between anonymous signing and signing after logging in?

The following is a detailed introduction to the differences between anonymous signing and signing after logging in: After you log in to the eSignGlobal platform and click the corresponding signing button in the envelope list to enter the signing link, if you open this signing link again in another browser, the system will require you to log in first. Only after a successful login can you enter the signing page to carry out the subsequent signing work. This signing method that requires logging in first before entering the signing page is called signing after logging in. There are two common situations that fall under anonymous signing. Firstly, when you directly click on the signing link in your email or copy the signing link received in your email and then paste it into any browser to open it, the system will directly guide you to the signing page without requiring you to log in. This is one manifestation of anonymous signing. Secondly, when you open the signing link obtained after initiating signing through the OpenAPI interface using a browser, it also allows you to directly enter the signing page without requiring the user to log in. This also belongs to the category of anonymous signing. Briefly speaking, signing after logging in requires logging in first before entering the signing page, while anonymous signing allows you to directly enter the signing page to carry out the signing work without logging in. There are obvious operational differences between the two in the step of entering the signing page.

When initiating an envelope via OpenAPI, an error message {"code":"120142","message":"Signer XXX does not support enabling security mode for automatic signing."} will be reported.

When you initiate an envelope via OpenAPI, if you receive the error message {"code":"120142","message":"Signer XXX does not support enabling security mode for automatic signing."}, it usually means that during the process of initiating the envelope, you have set the automatic (silent) signing function while also enabling the authentication mode at the same time, and this situation is not supported. In order to initiate the envelope smoothly and avoid such error messages, it is recommended that you handle the "authModes" parameter accordingly in the relevant operations. You can choose to set the value of the "authModes" parameter to 0 or directly adopt the default way, that is, not passing this parameter, so as to ensure that the whole process of initiating the envelope can proceed normally.

After initiating an envelope using the OpenAPI template, the size and position of the signature and seal areas on the signing page are inconsistent with the width, height and position set in the template.

When an envelope is initiated using the OpenAPI template and you find that the size and position of the signature and seal areas on the signing page are inconsistent with the width, height and position preset in the template, you can follow the steps below to troubleshoot and solve the problem: Firstly, it is necessary to carefully check the relevant information about the signature area returned by the /esignglobal/v1/templates/renderTask interface, with a focus on the specific parameters regarding its width, height and position. Then, compare the width, height and position information of the signature area obtained through this interface with the corresponding width, height and position parameters passed when initiating the operation via OpenAPI. If it is found through comparison that the two are inconsistent, then it is necessary to make corresponding changes to the width, height and coordinate parameters of the signature area passed when initiating the operation via OpenAPI. Make sure that they are completely consistent with the width, height and position of the signature area obtained by calling the /esignglobal/v1/templates/renderTask interface. Only in this way can it be ensured that the presentation effect of the signature and seal areas on the signing page meets the preset requirements of the template.