Bulk document signing via server-side processing enables multiple documents to be signed in a single operation, significantly reducing processing time for enterprises dealing with large document volumes. This feature is particularly useful for industries like finance, legal, and corporate contract management, where a standardized signing approach is required. By ensuring uniform signing policies across all documents in a batch, organizations can streamline operations while maintaining compliance. Supported signing methods for server-side bulk document signing including ADSS, RAS, and CSC signing.
To perform ADSS bulk document signing via API using server-side signing, follow the steps mentioned below. These steps detail the API calls required to sign multiple documents in a single operation through the server.
The signatory is identified via the access token provided in the API call, which means authentication is required before initiating the signing process. The access token must be issued directly to the signatory through authentication API.
If modifications are needed before signing, the Fill Form Fields API should be called beforehand. Note that any mandatory input fields must be completed for the signing process to succeed.
To determine which Signing Servers should be displayed based on a signature field’s level of assurance, the signature application must call the Get Signature Settings API. This API provides details of all available signing servers along with their corresponding levels of assurance.
The signature application needs to call Bulk Signing Pre Validation API. This API executes pre-signing validations for each document package and respectively returns any errors along with the list of tasks that the application needs to perform to complete the signing process.
If OTP authentication is turned on for the server-side signing operation which could be found in the response of Get Signature Settings API, client applications will need to generate an OTP for the mobile number using Bulk OTP Signing Authentication API call. Respective business applications must retrieve the OTP from the use and submit it when making the Bulk Sign Packages API call. This is done using the "x-otp" header in the request.
The signature application needs to call Bulk Sign Packages API. This API will sign/sign & share and share multiple documents (both electronic and digital) without displaying the documents to the end user.
Bulk Signing Status API will be used to get the status of a specific bulk signing transaction along with the details of document packages that were processed by the previous API call (repetitive call until status becomes COMPLETED).
Finally, after signing, the Get Document Verification API can be used to retrieve the verification response.
To perform RAS bulk document signing via API using server-side signing, follow the steps mentioned below. These steps detail the API calls required to sign multiple documents in a single operation through the server.
The signatory is identified via the access token provided in the API call, which means authentication is required before initiating the signing process. The access token must be issued directly to the signatory through authentication API.
If modifications are needed before signing, the Fill Form Fields API should be called beforehand. Note that any mandatory input fields must be completed for the signing process to succeed.
To determine which Signing Servers should be displayed based on a signature field’s level of assurance, the signature application must call the Get Signature Settings API. This API provides details of all available signing servers along with their corresponding levels of assurance.
The signature application needs to call Bulk Signing Pre Validation API. This API executes pre-signing validations for each document package and respectively returns any errors along with the list of tasks that the application needs to perform to complete the signing process.
The signature application needs to call Bulk Sign Packages API. This API will sign/sign & share and share multiple documents without displaying the documents to the end user. This API will respond with a "Pending" status. At this point, the server will send the authorization request to the client device.
Bulk Signing Status API will be used to get the status of a specific bulk signing transaction along with the details of document packages that were processed by the previous API call (repetitive call until status becomes COMPLETED).
Finally, after signing, the Get Document Verification API can be used to retrieve the verification response.
To perform CSC bulk document signing via API using server-side signing, follow the steps mentioned below. These steps detail the API calls required to sign multiple documents in a single operation through the server.
1. The signatory is identified via the access token provided in the API call, which means authentication is required before initiating the signing process. The access token must be issued directly to the signatory through authentication API.
2. If modifications are needed before signing, the Fill Form Fields API should be called beforehand. Note that any mandatory input fields must be completed for the signing process to succeed.
3. To determine which Signing Servers should be displayed based on a signature field’s level of assurance, the signature application must call the Get Signature Settings API. This API provides details of all available signing servers along with their corresponding levels of assurance.
4. The signature application needs to call Bulk Signing Pre Validation API. This API executes pre-signing validations for each document package and respectively returns any errors along with the list of tasks that the application needs to perform to complete the signing process.
5. The signature application uses the "" API to get the RSSP (Remote Signing Service Provider) information that is needed to perform CSC Signing.
6. The signature application uses the "" API which returns the information about the RSSP (Remote Signing Service Provider) and the list of API methods it has implemented. This method shall be implemented by any RSSP conforming to this specification.
7. The signature application gets the access token using the "" API, the Server will itself decide the grant_type (client_credentials / authorization_code) depending on its configurations.
8. The signature application gets the list of credentials associated using the "" API. if the RUT filtration is required this API will filter the credentials as per the RUT values. A user may have one or multiple credentials hosted by a single remote signing service provider.
9. The signature application gets the information on a signing credential, its associated certificate, and a description of the supported authorization mechanism using the "" API.
10. If the "authorization_required" parameter is true, in response to the "" API, the "" API shall be used to get the account_token which will be used to hit the "oauth2/authorize" CSC Server endpoint.
11. Use the "" API to get the hash of the document.
11. Signature application can use any one of the following APIs for authorization of credential ID, based on the response of the "" API of the CSC server:
"" API to start the online OTP mechanism associated with a credential ID for Explicit (OTP) authorization.
"" API to authorize access to the credential ID for signing for Explicit (OTP/PIN) or Implicit authorization. The SAD received in response shall be used in the "" API request.
"oauth2/authorize" API to initiate an OAuth 2.0 authorization flow for the OAuth 2.0 authorization. The authorization is returned in the form of an authorization code, which the signature application shall then use to obtain the SAD via "" API. The SAD received in response shall be used in the "" API request.
12. Use the "" API to embed signatures in the document.
13. The signature application uses one of the following APIs of the CSC server for revoking access tokens, as per the requirement:
"" API to revoke the service access token or refresh token.
"" API to revoke an OAuth 2.0 access token or refresh token.
14. Finally, after signing, the API can be used to retrieve the verification response.
The CSC Signing process can be a one-step or two-step operation, depending on the SCAL value returned by the "" API response. The distinction lies in how the document hash is calculated and how the signature is embedded.
1-Step Sign:
Condition: If SCAL is 1 in the "" API response, the signature application need to call the "" API. This API will automatically calculate the document hash/s, sign it using the CSC server, and embed the signature directly into the document.
2-Step Sign:
1. The signatory is identified via the access token provided in the API call, which means is required before initiating the signing process. The access token must be issued directly to the signatory through API.
2. If modifications are needed before signing, the API should be called beforehand. Note that any mandatory input fields must be completed for the signing process to succeed.
3. To determine which Signing Servers should be displayed based on a signature field’s level of assurance, the signature application must call the API. This API provides details of all available signing servers along with their corresponding levels of assurance.
4. The signature application needs to call API. This API executes pre-signing validations for each document package and respectively returns any errors along with the list of tasks that the application needs to perform to complete the signing process.
5. The signature application uses the "" API to get the RSSP (Remote Signing Service Provider) information that is needed to perform CSC Signing.
6. The signature application uses the "" API which returns the information about the RSSP (Remote Signing Service Provider) and the list of API methods it has implemented. This method shall be implemented by any RSSP conforming to this specification.
7. If the "authorization_required" parameter is true, in response to the "" API, the "" API shall be used to get the account_token which will be used to hit the "oauth2/authorize" CSC Server endpoint.
8. The signature application requests authorization for the user to access the RSSP resources using the "oauth2/authorize" API of the CSC server. The authorization is returned in the form of an authorization code, which the signature application shall then use to obtain an access token.
9. The signature application gets the access token using the "" API which returns the Bearer/SAD token.
10. The signature application gets the list of credentials associated using the "" API. if the RUT filtration is required this API will filter the credentials as per the RUT values. A user may have one or multiple credentials hosted by a single remote signing service provider.
11. The signature application gets the information on a signing credential, its associated certificate, and a description of the supported authorization mechanism using the "" API.
12. Use the "" API to get the hash of the document.
12. Signature application can use any one of the following API for authorization of credential ID, based on the response of the "" API of the CSC server:
"" API to start the online OTP mechanism associated with a credential ID for Explicit (OTP) authorization.
"" API to authorize access to the credential ID for signing for Explicit (OTP/PIN) or Implicit authorization. The SAD received in response shall be used in the "" API request.
"oauth2/authorize" API to initiate an OAuth 2.0 authorization flow for the OAuth 2.0 authorization. The authorization is returned in the form of an authorization code, which the signature application shall then use to obtain the SAD via "" API. The SAD received in response shall be used in the "" API request.
13. Use the "" API to embed signatures in the document.
14. The signature application uses one of the following APIs of the CSC server for revoking access tokens, as per the requirement:
"" API to revoke the service access token or refresh token.
"" API to revoke an OAuth 2.0 access token or refresh token.
15. Finally, after signing, the API can be used to retrieve the verification response.
The CSC Signing process can be a one-step or two-step operation, depending on the SCAL value returned by the "" API response. The distinction lies in how the document hash is calculated and how the signature is embedded.
1-Step Sign:
Condition: If SCAL is 1 in the "" API response, the signature application need to call the "" API. This API will automatically calculate the document hash/s, sign it using the CSC server, and embed the signature directly into the document.
2-Step Sign:
Condition: If SCAL is 2 in the "" API response, the following steps are required:
Process: Follow the below steps:
First, the signature application must call the "" API to retrieve the document’s hash.
Next, the application must call the "" API to embed the signature into the document.
Condition: If SCAL is 2 in the "" API response, the following steps are required:
Process: Follow the below steps:
First, the signature application must call the "" API to retrieve the document’s hash.
Next, the application must call the "" API to embed the signature into the document.