UANATACA SIGNBOX API
UANATACA SIGNBOX API DOCUMENTATION (1.0)
What it is
The high-performance solution for Bulk, Interactive and LTV signature service. Our best option for signing large number of documents and transactions.
SignBox API is an enterprise-grade solution for automated electronic signature of any type of file or document. A turnkey system that can be easily integrated with any business application without altering the user experience and guaranteeing the legal security of your electronically signed documents. SignBox API is a high-level web API based on the http RESTful paradigm.
How it works
The API is given with SignBox Optimizer that is a server system exposing http RESTful API by means of which, business applications are enabled to require the electronic signature of large number of documents.
SignBox Optimizer performs the most computationally expensive workload of the signature process, thus reducing the data traffic on the local network and make the most of the cryptographic hardware acceleration. The documents to be signed are processed in the customer business layer and are not send to Uanataca Services, instead is sent a hash of the document created using a hash algorithm. For environments demanding high performance, SignBox can be coupled with a pool of SignBox Optimizer.
The system provides options for several electronic signature formats including time stamping and long term validation. The electronic signatures are performed in Uanataca Trusted Service Center side, where signature keys are stored in a Qualified Electronic Signature Creation Device (QSCD) system.
Sandbox Environment
For testing purposes, Uanataca provides integrators of a pre-configured test-mode SignBox Optimizer accessible at the following URL:
https://signbox.developers.uanataca.com
Want to configure your own test-mode Optimizer? Find instructions in the configuration section.
Configuration
SignBox Optimizer can be supplied as a Docker image. See the configuration description in:
SignBox Optimizer on Docker
Hardware requirements
CPU: modern multicore (minimum 4 core)
RAM: 8GB
HDD: 200 GB
SignBox Optimizer on Docker
This configuration requires a server with a Linux operating system.
The commands show belown are suitable for Ubuntu. Each Linux distribution will require it's own commands.
STEP 1: Install Docker and Docker-Compose.
Docker and Docker-Compose
Run the following commands in this order.
# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
# Add the repository to Apt sources:
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl start docker
Run command sudo docker run hello-world to check the installation.
STEP 2: Extract and copy SignBox Optimizer zip content to the server.
Extract all optimizer_docker.zip
content in a local folder.
Move uanataca_optimizer folder to the path /opt in the server.
The outcome should look like this:
STEP 3: Mapping volumes (for environments with a pool of SignBox Optimizer).
In high performance environments with a pool of SignBox Optimizer, service settings and logs must be stored in a shared volume outside Optimizer servers. These volumes must be defined in docker-compose.yml
file in each SignBox Optimizer.
cd /opt/uanataca_optimizer
Docker-compose.yml settings file:
STEP 4: Load SignBox Docker image.
Run the following commands:
Remove image file:
STEP 5: Launch the service.
Run:
Check service status:
All services must be UP.
Signature Image Configuration
A visual signature can be placed as an image in the signed document. The visual signature is composed by an image and text.
These are the parameters that you can enable to use this feature:
Parameter | Description | Example |
---|---|---|
position | Coordinates where you want to place the graphical signature box. Input must follow (x1,y1,x2,y2) , where: x1 belongs to Left X Coordinate (measured from page left side) y1 belongs to Bottom Y Coordinate (measured from page bottom) x2 belongs to Right X Coordinate (measured from page left side) y2 belongs to Top Y Coordinate (measured from page bottom) | 300,100,500,150
|
signature_appearance | Graphical signature details structure. See description | <Stack background="iVBORw0KGgoAAAANSUhEUgAAAK8AAACvCAYA"> </Stack> |
signature_ids | PDF signature field ids to sign (Example: signature1,signature2) | signature1,signature2 |
Signature appearance
Available tags:
<Grid>
<Stack>
<Paragraph>
Available tag attributes:
background
Available text variables:
$(CN)s : CommonName
$(L)s : Locality
$(S)s : stateOrProvinceName
$(OU)s : organizationalUnitName
$(E)s : email
$(Email)s : email included in the Subject Alternative Name
$(Issuer)s : Certificate CA Issuer Common Name
$(date)s : Date and time of the signature. Compliant to ISO 8601 standard.
$(reason)s : “bit4-reason” parameter value
$(location)s : “bit4-location” parameter value
Webhooks
SignBox API requires that the customer business develop a webhook to manage the service callbacks. There are two callbacks in the service that must be set in the parameters url_out
and urlback
of the SIGN API call.
urlback
The service logs are sent as a string in a HTTP POST request to the webhook url defined in this parameter.
Below you can see message samples.
Successful response:
Error response:
url_out
In a successful signature process, the result signed file is sent as a binary file in a HTTP POST request to the webhoook url defined in this parameter.
Rootstore configuration
As a requirement for LTV/LTVLITE signature level, we must add to the optimizer every chain of trust for each certificate that is involved in the signature.
In case that you don't make use of LTV/LVTLITE signature level, this process is NOT necessary.
This process vary depending on the selected optimizer install method.
Every certificate introduced in the optimizer regarding the rootstore needs to be formatted as a PEM file and introduced in a specific folder. Below an example of the general structure that is needed.
Note: Number of lines below the header are not representative of a real certificate.
STEP 1: Load certificates in the optimizer
Load the PEM files in the following path:
STEP 2: Restart the service
After all the desired certificates have been loaded into the optimizer, we must execute the following command on the container
Logs
Service logs are stored in the running docker container. You can reach them executing:
Postman collection
A postman collection is available as a support for a quick start.
It is only required to edit host
variable in Postman environment with the IP or domain of SignBox Optimizer.
SignBox Postman collection download