Single document signing through server-side processing enables an individual document to be signed automatically via API using server-side certificates. Since the signing process occurs without user intervention, it provides an efficient and secure way for businesses to handle legally binding signatures programmatically. This method enhances security by utilizing server-stored certificates and ensures compliance with digital signature regulations, making it particularly useful for industries requiring automated, high-trust signing solutions. SigningHub supports ADSS, RAS, CSC, and eID Easy signing for single documents.
To perform ADSS signatures via API using server-side signing, follow the steps mentioned below. These steps outline the necessary API calls and conditions to successfully complete a single document signing 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 API. This API provides details of all available signing servers along with their corresponding levels of assurance.
If OTP authentication is turned on for the server side signing operation which could be find in the response of API, client applications will need to generate an OTP for the mobile number using API call. Respective business applications must retrieve the OTP from the use and submit it when making the API call. This is done using the "x-otp" header in the request.
Signature applications can use API to sign a single document (both electronic and digital).
You will get verification object in the response of this API if the request parameter skip_verification is not passed or set to false.
After the signing process is complete, if the signatory is the final signer, the API must be invoked. Without this step, the document will remain in an "In Progress" state for the owner. Once the API is called, the status updates to "Completed."
Finally, after signing, the API can be used to retrieve the verification response.
To perform RAS signatures via API using server-side signing, follow the steps mentioned below. These steps outline the necessary API calls and conditions to successfully complete a single document signing 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 API. This API provides details of all available signing servers along with their corresponding levels of assurance.
Signature applications can use API to sign a single document. This API will respond with a "Pending" status if all validations are done. At this point, the server will send the authorization request to the client device.
API will be used to get the status of signing that were processed by the previous API call (repetitive call until status become COMPLETED).
You will get verification object in the response of this API if the request parameter skip_verification is not passed or set to false. (on success)
After the signing process is complete, if the signatory is the final signer, the API must be invoked. Without this step, the document will remain in an "In Progress" state for the owner. Once the API is called, the status updates to "Completed."
Finally, after signing, the API can be used to retrieve the verification response.
To perform CSC signatures via API using server-side signing, follow the steps mentioned below. These steps outline the necessary API calls and conditions to successfully complete a single document signing operation through the server.
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
To perform eID Easy signatures via API using server-side signing, follow the steps mentioned below. These steps outline the necessary API calls and conditions to successfully complete a single document signing operation through the server.
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.
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.
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.
Prepare the document for signing using the Pre eID Easy Signing API. In this step, the initial data, including the document, signature details, and document hash, is uploaded to the eID Easy server at the configured connector address. In response, the server returns a unique document ID along with the available signing methods, which will be used in subsequent API calls.
The signing methods retrieved from the Pre eID Easy Signing API response will be used in the eID Easy widget to display the available signing servers. The user selects a signing method and completes the signing process on the widget window. Once the signing is completed, the eID Easy server sends a response on eID Easy Webhook which will receive the certificate details and the system will respond with the data to be signed in Hex Decimal format.
The webhook is configured in the eID Easy admin panel under the Custom CAdES Digest Webhook field.
After receiving the webhook response, the eID Easy server triggers a success callback. At this stage, the Post eID Easy Signing API is invoked to retrieve the PKCS7 signature value and perform the signature assembly process, finalizing the signing operation.
After the signing process is complete, if the signatory is the final signer, the Finish Processing API must be invoked. Without this step, the document will remain in an "In Progress" state for the owner. Once the API is called, the status updates to "Completed."
Finally, after signing, the Get Document Verification API can be used to retrieve the verification response.
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 uses the "Get RSSP Information" API to get the RSSP (Remote Signing Service Provider) information that is needed to perform CSC Signing.
5. The signature application uses the "Get RSSP Info" 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.
6. The signature application gets the access token using the "Get Access Token | SAD" API, Server will itself decide the grant_type (client_credentials / authorization_code) depending on its configurations.
7. The signature application gets the list of credentials associated using the "Get Filtered Credential List" 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.
8. The signature application gets the information on a signing credential, its associated certificate, and a description of the supported authorization mechanism using the "Get Credentials Info" API.
9. If the "authorization_required" parameter is true, in response to the "Get RSSP Information" API, the "Get Account Token" API shall be used to get the account_token which will be used to hit the "oauth2/authorize" CSC Server endpoint.
10. Use the "Get Document Hash" API to get the hash of the document.
Signature application can use any one of the following API for authorization of credential ID, based on the response of the "Get Credentials Info" API of the CSC server:
"Send OTP via RSSP" API to start the online OTP mechanism associated with a credential ID for Explicit (OTP) authorization.
"RSSP Credentials 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 "Get Sign Hash from RSSP" 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 "Get Access Token | SAD" API. The SAD received in response shall be used in the "Get Sign Hash from RSSP" API request.
11. Use the "Embed Signature" API to embed signatures in the document.
12. The signature application uses one of the following APIs of the CSC server for revoking access tokens, as per the requirement:
"Revoke Access Token" API to revoke the service access token or refresh token.
"Revoke OAuth2 Access Token" API to revoke an OAuth 2.0 access token or refresh token.
13. After the signing process is complete, if the signatory is the final signer, the Finish Processing API must be invoked. Without this step, the document will remain in an "In Progress" state for the owner. Once the API is called, the status updates to "Completed."
Finally, after signing, the Get Document Verification 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 "Get Credentials Info" 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 "Get Credentials Info" API response, the signature application does not need to call the "Get Document Hash" API to calculate the document hash.
Process: The application simply collects the necessary data to call the "Sign Document via RSSP Directly" API. This API will automatically calculate the document hash, 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.
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 uses the "Get RSSP Information" API to get the RSSP (Remote Signing Service Provider) information that is needed to perform CSC Signing.
5. The signature application uses the "Get RSSP Info" 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.
6. If the "authorization_required" parameter is true, in response to the "Get RSSP Information" API, the "Get Account Token" API shall be used to get the account_token which will be used to hit the "oauth2/authorize" CSC Server endpoint.
7. 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.
8. The signature application gets the access token using the "Get Access Token | SAD" API which returns the Bearer/SAD token.
9. The signature application gets the list of credentials associated using the "Get Filtered Credential List" 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.
10. The signature application gets the information on a signing credential, its associated certificate, and a description of the supported authorization mechanism using the "Get Credentials Info" API.
11. Use the "Get Document Hash" 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 "Get Credentials Info" API of the CSC server:
"Send OTP via RSSP" API to start the online OTP mechanism associated with a credential ID for Explicit (OTP) authorization.
"RSSP Credentials 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 "Get Sign Hash from RSSP" 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 "Get Access Token | SAD" API. The SAD received in response shall be used in the "Get Sign Hash from RSSP" API request.
12. Use the "Embed Signature" 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:
o "Revoke Access Token" API to revoke the service access token or refresh token.
o "Revoke OAuth2 Access Token" API to revoke an OAuth 2.0 access token or refresh token.
14. After the signing process is complete, if the signatory is the final signer, the Finish Processing API must be invoked. Without this step, the document will remain in an "In Progress" state for the owner. Once the API is called, the status updates to "Completed."
Finally, after signing, the Get Document Verification 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 "Get Credentials Info" 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 "Get Credentials Info" API response, the signature application does not need to call the "Get Document Hash" API to calculate the document hash.
Process: The application simply collects the necessary data to call the "Sign Document via RSSP Directly" API. This API will automatically calculate the document hash, 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:
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.
Next, the application must call the "" API to embed the signature into the document.